Howto: Profiling GCJ code?

Mon Jun 29 04:54:00 GMT 2009

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
>>