Howto: Profiling GCJ code?

[Patrick Schäfer]

to be true, I am not really familiar with debugging libgcj or native  
libraries. I do know how to debug java from eclipse, but I guess that  
is not applicable here.
could you give me a hint, which tool(s) to start with?

thank you

patrick

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