Re: Howto: Profiling GCJ code?
Patrick Schäfer <[email protected]>
| Newsgroups | gmane.comp.gcc.java.devel |
|---|---|
| Message-ID | <[email protected]> |
to be true, I am not really familiar with debugging libgcj or native libraries. I do know how to debug java from eclipse, but I guess that is not applicable here. could you give me a hint, which tool(s) to start with? thank you patrick > It looks like lots of large objects are being allocated in rapid > succession, and this is forcing very frequent GCs since the heap is > being exhausted repeatedly. You might try a breakpoint in > gc_alloc_large, and looking at every 1000th call or so to see > whether there is a good reason for this, and to make sure that the > allocation size is plausible. Setting the GC_PRINT_STATS > environment variable might also tell you something useful. > > Hans > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> On Behalf Of Patrick Schäfer >> Sent: Friday, June 26, 2009 6:15 AM >> To: Andrew Pinski >> Cc: Bryce McKinlay; [email protected]; Ian Rogers >> Subject: Re: Howto: Profiling GCJ code? >> >> thanx for the help. >> >> I finally had time to profile my application using Shark. >> >> The results are interesting: >> >> 0.1% 63.4% libgcj.9.dylib _Jv_NewPrimArray >> 0.1% 61.8% libgcj.9.dylib GC_local_malloc_atomic >> 0.0% 61.5% libgcj.9.dylib GC_malloc_atomic >> 0.3% 61.0% libgcj.9.dylib GC_generic_malloc >> 0.1% 60.0% libgcj.9.dylib GC_alloc_large >> 0.0% 57.9% libgcj.9.dylib GC_collect_or_expand >> 0.0% 57.9% libgcj.9.dylib GC_try_to_collect_inner >> 0.0% 56.4% libgcj.9.dylib GC_stopped_mark >> 0.0% 56.3% libgcj.9.dylib GC_mark_some >> 38.5% 55.6% libgcj.9.dylib GC_mark_from >> 0.3% 0.3% libgcj.9.dylib >> GC_add_to_black_list_normal >> 0.0% 0.2% libgcj.9.dylib GC_push_roots >> 0.0% 0.1% libgcj.9.dylib >> GC_push_next_marked_uncollectable >> 0.0% 0.0% libgcj.9.dylib GC_next_used_block >> 0.0% 0.0% libgcj.9.dylib __i686.get_pc_thunk.bx >> 0.0% 0.1% libgcj.9.dylib GC_stop_world >> 0.0% 0.0% libgcj.9.dylib GC_start_world >> 0.0% 0.0% libgcj.9.dylib GC_never_stop_func >> 0.0% 0.0% libSystem.B.dylib task_threads >> 0.0% 1.2% libgcj.9.dylib GC_finish_collection >> 0.0% 0.3% libgcj.9.dylib GC_clear_marks >> 0.0% 0.0% libgcj.9.dylib GC_promote_black_lists >> 0.0% 0.0% libgcj.9.dylib GC_start_world >> 0.0% 0.0% libgcj.9.dylib GC_mark_some >> 0.2% 2.0% libgcj.9.dylib GC_allochblk >> 0.1% 0.1% libgcj.9.dylib GC_hblk_fl_from_blocks >> 0.0% 0.0% libgcj.9.dylib GC_allochblk_nth >> 0.0% 0.0% libgcj.9.dylib __i686.get_pc_thunk.bx >> ... >> >> This indicates the program is busy allocating memory for >> almost all the time - even after the connection is lost, the >> cpu-cost is up at 100%. So there is almost no cpu cost while >> there is no java.nio connection. As soon as the java.nio >> connection is established, the cpu- cost goes up to 100% and >> stays there even after the connection is disconnected. >> >> any idea why java.nio has this bad memory allocation behavior >> or how to solve this? >> >> I tried using APR (apache portable runtime) as a transport >> layer, and, to my surprise, this does solve the problem. >> Though this is a solution, I am not to happy about using APR, >> as this adds another native library which has to be on the >> client to run the application. >> >> patrick >> >> >> >> Am 23.06.2009 um 00:53 schrieb Andrew Pinski: >> >>> On Mon, Jun 22, 2009 at 3:49 PM, Bryce McKinlay<[email protected]> >>> wrote: >>>> In OS X you could try Shark, which comes with Apple's developer >>>> tools. >>>> I don't know how well it plays with libgcj, but it's >> probably worth a >>>> shot. >>> >>> Shark works nicely with GCJ, I have used it before but that >> was almost >>> 5 years ago now. :) >>> >>> -- Pinski >> >>