Howto: Profiling GCJ code?

Howto: Profiling GCJ code?

[Patrick Schäfer]

Hi,

I am trying to run a server based on apache mina (java.nio) and jna  
for native library access. The program runs just fine under jdk 1.5.  
But there is a massive performance breakdown using gcj. The program  
basically polls a Posix Message Queue every 500ms using JNA (JNI).  
This causes 5% cpu load on jdk but the load goes up to 100% using gcj.

Is there any profiling tool which can be easily installed and applied  
to the native code?

I read about profiling gcj applications on your faq. There are 3 tools  
mentioned. To my understanding gprof can't be applied due to missing  
multithreading support and it requires the program to exit main before  
writing any profiling information. The later is not easy when using a  
network server. cprof seems to be quite outdated (there has been no  
realease within the last years) and trying to "make" it, fails with  
several errors. I don't know about sprof, but I couldn't find much  
information about it on the internet.

Thank you for any hints about current multithreading gcj (gcc) profilers

Patrick 

Re: Howto: Profiling GCJ code?

[Bryce McKinlay]

The tool of choice for libgcj profiling is oprofile:
http://oprofile.sourceforge.net/

This should give you reasonably accurate, low-overhead profiling
without having to recompile anything, and even a call graph though
both the java and C/C++ code.

It doesn't surprise me that libgcj's java.nio is slow. Hotspot VMs can
also optimize nio code in ways that gcj can't.

Bryce


On Fri, Jun 19, 2009 at 9:52 AM, Patrick Schäfer<ps@ekse.de> wrote:
> Hi,
>
> I am trying to run a server based on apache mina (java.nio) and jna for
> native library access. The program runs just fine under jdk 1.5. But there
> is a massive performance breakdown using gcj. The program basically polls a
> Posix Message Queue every 500ms using JNA (JNI). This causes 5% cpu load on
> jdk but the load goes up to 100% using gcj.
>
> Is there any profiling tool which can be easily installed and applied to the
> native code?
>
> I read about profiling gcj applications on your faq. There are 3 tools
> mentioned. To my understanding gprof can't be applied due to missing
> multithreading support and it requires the program to exit main before
> writing any profiling information. The later is not easy when using a
> network server. cprof seems to be quite outdated (there has been no realease
> within the last years) and trying to "make" it, fails with several errors. I
> don't know about sprof, but I couldn't find much information about it on the
> internet.
>
> Thank you for any hints about current multithreading gcj (gcc) profilers
>
> Patrick
>

Re: Howto: Profiling GCJ code?

[Ian Rogers]

Hi,

I just wanted to add a note that to improve the nio performance for
the DaCapo benchmark suite certain special cases were optimized in
Jikes RVM's usage of VMChannel from Classpath (LGPL source visible at
[1]). The FileSystem object within JikesRVM just provides a means to
access open/close/read/write calls without the overhead of JNI (in
much the same way as CNI does for GCJ). There exists CNI channel code,
if nio is a performance problem I believe something can be learnt from
the RVM code base as I don't believe NIO is a performance issue in the
RVM any more.

Regards,
Ian

[1] http://git.codehaus.org/gitweb.cgi?p=mrp.git;a=blob;f=libraryInterface/GNUClasspath/LGPL/src/gnu/java/nio/VMChannel.java;h=8edf32bbf1d630c34b8db317c25376ba85e2a930;hb=HEAD
--
Metacircular Research Platform ( http://mrp.codehaus.org/ ), supports
the development of optimized metacircular Virtual Machines in Java on
Linux, OS/X and Windows.

2009/6/19 Bryce McKinlay <bmckinlay@gmail.com>:
> The tool of choice for libgcj profiling is oprofile:
> http://oprofile.sourceforge.net/
>
> This should give you reasonably accurate, low-overhead profiling
> without having to recompile anything, and even a call graph though
> both the java and C/C++ code.
>
> It doesn't surprise me that libgcj's java.nio is slow. Hotspot VMs can
> also optimize nio code in ways that gcj can't.
>
> Bryce
>
>
> On Fri, Jun 19, 2009 at 9:52 AM, Patrick Schäfer<ps@ekse.de> wrote:
>> Hi,
>>
>> I am trying to run a server based on apache mina (java.nio) and jna for
>> native library access. The program runs just fine under jdk 1.5. But there
>> is a massive performance breakdown using gcj. The program basically polls a
>> Posix Message Queue every 500ms using JNA (JNI). This causes 5% cpu load on
>> jdk but the load goes up to 100% using gcj.
>>
>> Is there any profiling tool which can be easily installed and applied to the
>> native code?
>>
>> I read about profiling gcj applications on your faq. There are 3 tools
>> mentioned. To my understanding gprof can't be applied due to missing
>> multithreading support and it requires the program to exit main before
>> writing any profiling information. The later is not easy when using a
>> network server. cprof seems to be quite outdated (there has been no realease
>> within the last years) and trying to "make" it, fails with several errors. I
>> don't know about sprof, but I couldn't find much information about it on the
>> internet.
>>
>> Thank you for any hints about current multithreading gcj (gcc) profilers
>>
>> Patrick
>>
>

Re: Howto: Profiling GCJ code?

[Patrick Schäfer]

thank you for the help!

oprofiler is quite troublesome to build on my mac os x as there a lots  
of libraries missing. currently "bfd" (-lbfd) is missing.

therefor I am still not sure if java.nio is the main reason for the  
performance bottleneck but apache mina is also capable of using APR as  
a transport layer (instead of java.nio).  that could improve overall  
performance too.

patrick



Am 22.06.2009 um 15:35 schrieb Ian Rogers:

> Hi,
>
> I just wanted to add a note that to improve the nio performance for
> the DaCapo benchmark suite certain special cases were optimized in
> Jikes RVM's usage of VMChannel from Classpath (LGPL source visible at
> [1]). The FileSystem object within JikesRVM just provides a means to
> access open/close/read/write calls without the overhead of JNI (in
> much the same way as CNI does for GCJ). There exists CNI channel code,
> if nio is a performance problem I believe something can be learnt from
> the RVM code base as I don't believe NIO is a performance issue in the
> RVM any more.
>
> Regards,
> Ian
>
> [1] http://git.codehaus.org/gitweb.cgi?p=mrp.git;a=blob;f=libraryInterface/GNUClasspath/LGPL/src/gnu/java/nio/VMChannel.java;h=8edf32bbf1d630c34b8db317c25376ba85e2a930;hb=HEAD
> --
> Metacircular Research Platform ( http://mrp.codehaus.org/ ), supports
> the development of optimized metacircular Virtual Machines in Java on
> Linux, OS/X and Windows.
>
> 2009/6/19 Bryce McKinlay <bmckinlay@gmail.com>:
>> The tool of choice for libgcj profiling is oprofile:
>> http://oprofile.sourceforge.net/
>>
>> This should give you reasonably accurate, low-overhead profiling
>> without having to recompile anything, and even a call graph though
>> both the java and C/C++ code.
>>
>> It doesn't surprise me that libgcj's java.nio is slow. Hotspot VMs  
>> can
>> also optimize nio code in ways that gcj can't.
>>
>> Bryce
>>
>>
>> On Fri, Jun 19, 2009 at 9:52 AM, Patrick Schäfer<ps@ekse.de> wrote:
>>> Hi,
>>>
>>> I am trying to run a server based on apache mina (java.nio) and  
>>> jna for
>>> native library access. The program runs just fine under jdk 1.5.  
>>> But there
>>> is a massive performance breakdown using gcj. The program  
>>> basically polls a
>>> Posix Message Queue every 500ms using JNA (JNI). This causes 5%  
>>> cpu load on
>>> jdk but the load goes up to 100% using gcj.
>>>
>>> Is there any profiling tool which can be easily installed and  
>>> applied to the
>>> native code?
>>>
>>> I read about profiling gcj applications on your faq. There are 3  
>>> tools
>>> mentioned. To my understanding gprof can't be applied due to missing
>>> multithreading support and it requires the program to exit main  
>>> before
>>> writing any profiling information. The later is not easy when  
>>> using a
>>> network server. cprof seems to be quite outdated (there has been  
>>> no realease
>>> within the last years) and trying to "make" it, fails with several  
>>> errors. I
>>> don't know about sprof, but I couldn't find much information about  
>>> it on the
>>> internet.
>>>
>>> Thank you for any hints about current multithreading gcj (gcc)  
>>> profilers
>>>
>>> Patrick
>>>
>>

Re: Howto: Profiling GCJ code?

[Bryce McKinlay]

On Mon, Jun 22, 2009 at 8:25 PM, Patrick Schäfer<ps@ekse.de> wrote:
> thank you for the help!
>
> oprofiler is quite troublesome to build on my mac os x as there a lots of
> libraries missing. currently "bfd" (-lbfd) is missing.
>
> therefor I am still not sure if java.nio is the main reason for the
> performance bottleneck but apache mina is also capable of using APR as a
> transport layer (instead of java.nio).  that could improve overall
> performance too.

oprofile requires explicit kernel support to work, and as far as I
know, it only works on Linux.

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.

Bryce

Re: Howto: Profiling GCJ code?

[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

Re: Howto: Profiling GCJ code?

[Patrick Schäfer]

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

RE: Howto: Profiling GCJ code?

[Boehm, Hans]

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

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

Re: Howto: Profiling GCJ code?

[Patrick Schäfer]

Hi,

I tried exchanging java.nio with the apache portable runtime (APR)  
library which solves the issue with the garbage collector consuming  
most of the time (>80%) even while being idle. But it causes the  
application to spend most cycles in dynamically loading libraries at  
runtime under load. I am extensively using JNA (JNI) for Posix Message  
Queues and APR as transport layer which both use JNI for native  
library access.

It seems to me like those libraries are dynamically loaded for every  
method call. I couldn't find a way to statically bind the libraries on  
mac os x. Is there a way to cache methods or any other way to improve  
this?

Profile:

	Self		Total	Library
	0.0%	89.9%	Unknown Library	0x696d5f74 [unreadable]	
	0.0%	89.8%	libgcj.9.dylib	 _Jv_platform_dladdr(void*, _Jv_AddrInfo*)	
	0.0%	89.8%	libSystem.B.dylib	  dladdr	
	24.2%	82.9%	dyld	   dladdr	
	28.9%	28.9%	dyld	    ImageLoaderMachO::getSymbolAddress(macho_nlist  
const*, ImageLoader const*, ImageLoader::LinkContext const&) const	
	22.8%	22.8%	dyld	     
ImageLoaderMachO::getIndexedExportedSymbol(unsigned int) const	
	6.9%	6.9%	dyld	     
ImageLoaderMachO::getExportedSymbolAddress(ImageLoader::Symbol const*,  
ImageLoader::LinkContext const&, ImageLoader const*) const	
	0.0%	0.0%	dyld	    dyld::findImageContainingAddress(void const*)	
	0.0%	0.0%	dyld	    ImageLoader::containsAddress(void const*) const	
	0.0%	0.0%	dyld	     
ImageLoaderMachO::getExportedSymbolName(ImageLoader::Symbol const*)  
const	
	0.0%	0.0%	dyld	    ImageLoader::getLogicalPath() const	
	2.3%	2.3%	dyld	   ImageLoaderMachO::getIndexedExportedSymbol(unsigned  
int) const	
	2.3%	2.3%	dyld	    
ImageLoaderMachO::getExportedSymbolAddress(ImageLoader::Symbol const*,  
ImageLoader::LinkContext const&, ImageLoader const*) const	
	2.2%	2.2%	dyld	   ImageLoaderMachO::getSymbolAddress(macho_nlist  
const*, ImageLoader const*, ImageLoader::LinkContext const&) const	



thank you for any help

patrick

Re: Howto: Profiling GCJ code?

[Andrew Haley]

Patrick Schäfer wrote:

> I tried exchanging java.nio with the apache portable runtime (APR)
> library which solves the issue with the garbage collector consuming most
> of the time (>80%) even while being idle. But it causes the application
> to spend most cycles in dynamically loading libraries at runtime under
> load. I am extensively using JNA (JNI) for Posix Message Queues and APR
> as transport layer which both use JNI for native library access.
> 
> It seems to me like those libraries are dynamically loaded for every
> method call. I couldn't find a way to statically bind the libraries on
> mac os x. Is there a way to cache methods or any other way to improve this?

JNI doesn't dynamically load a library for every call, although JNA might.
It seems there's a tremendous load on dladdr().

I'll have a look at the sources for JNA and get back to you.

Andrew.