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