Howto: Profiling GCJ code?

Patrick Schäfer ps@ekse.de
Fri Jun 26 13:15:00 GMT 2009


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



More information about the Java mailing list

AltStyle によって変換されたページ (->オリジナル) /