This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: Howto: Profiling GCJ code?
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: java-owner@gcc.gnu.org [mailto:java-owner@gcc.gnu.org]
> On Behalf Of Patrick Schäfer
> Sent: Friday, June 26, 2009 6:15 AM
> To: Andrew Pinski
> Cc: Bryce McKinlay; java@gcc.gnu.org; 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<bmckinlay@gmail.com>
> > 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
>
>