This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Howto: Profiling GCJ code?

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]