Re: Howto: Profiling GCJ code?

[Patrick Schäfer <ps at ekse dot de>]

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