* Howto: Profiling GCJ code? @ 2009-06-19 8:52 Patrick Schäfer 2009-06-19 9:47 ` Bryce McKinlay 0 siblings, 1 reply; 11+ messages in thread From: Patrick Schäfer @ 2009-06-19 8:52 UTC (permalink / raw) To: java 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Howto: Profiling GCJ code? 2009-06-19 8:52 Howto: Profiling GCJ code? Patrick Schäfer @ 2009-06-19 9:47 ` Bryce McKinlay 2009-06-22 13:35 ` Ian Rogers 0 siblings, 1 reply; 11+ messages in thread From: Bryce McKinlay @ 2009-06-19 9:47 UTC (permalink / raw) To: Patrick Schäfer; +Cc: java 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 > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Howto: Profiling GCJ code? 2009-06-19 9:47 ` Bryce McKinlay @ 2009-06-22 13:35 ` Ian Rogers 2009-06-22 19:25 ` Patrick Schäfer 0 siblings, 1 reply; 11+ messages in thread From: Ian Rogers @ 2009-06-22 13:35 UTC (permalink / raw) To: Bryce McKinlay; +Cc: Patrick Schäfer, java 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 >> > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Howto: Profiling GCJ code? 2009-06-22 13:35 ` Ian Rogers @ 2009-06-22 19:25 ` Patrick Schäfer 2009-06-22 22:50 ` Bryce McKinlay 0 siblings, 1 reply; 11+ messages in thread From: Patrick Schäfer @ 2009-06-22 19:25 UTC (permalink / raw) To: java; +Cc: Bryce McKinlay, Ian Rogers 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 >>> >> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Howto: Profiling GCJ code? 2009-06-22 19:25 ` Patrick Schäfer @ 2009-06-22 22:50 ` Bryce McKinlay 2009-06-22 22:53 ` Andrew Pinski 0 siblings, 1 reply; 11+ messages in thread From: Bryce McKinlay @ 2009-06-22 22:50 UTC (permalink / raw) To: Patrick Schäfer; +Cc: java, Ian Rogers 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Howto: Profiling GCJ code? 2009-06-22 22:50 ` Bryce McKinlay @ 2009-06-22 22:53 ` Andrew Pinski 2009-06-26 13:15 ` Patrick Schäfer 2009-06-30 18:38 ` Patrick Schäfer 0 siblings, 2 replies; 11+ messages in thread From: Andrew Pinski @ 2009-06-22 22:53 UTC (permalink / raw) To: Bryce McKinlay; +Cc: Patrick Schäfer, java, Ian Rogers 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Howto: Profiling GCJ code? 2009-06-22 22:53 ` Andrew Pinski @ 2009-06-26 13:15 ` Patrick Schäfer 2009-06-29 4:54 ` Boehm, Hans 2009-06-30 18:38 ` Patrick Schäfer 1 sibling, 1 reply; 11+ messages in thread From: Patrick Schäfer @ 2009-06-26 13:15 UTC (permalink / raw) To: Andrew Pinski; +Cc: Bryce McKinlay, java, Ian Rogers 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: Howto: Profiling GCJ code? 2009-06-26 13:15 ` Patrick Schäfer @ 2009-06-29 4:54 ` Boehm, Hans 2009-06-30 18:21 ` Patrick Schäfer 0 siblings, 1 reply; 11+ messages in thread From: Boehm, Hans @ 2009-06-29 4:54 UTC (permalink / raw) To: Patrick Schäfer, Andrew Pinski; +Cc: Bryce McKinlay, java, Ian Rogers 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 > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Howto: Profiling GCJ code? 2009-06-29 4:54 ` Boehm, Hans @ 2009-06-30 18:21 ` Patrick Schäfer 0 siblings, 0 replies; 11+ messages in thread From: Patrick Schäfer @ 2009-06-30 18:21 UTC (permalink / raw) To: Boehm, Hans; +Cc: java 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 >> >> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Howto: Profiling GCJ code? 2009-06-22 22:53 ` Andrew Pinski 2009-06-26 13:15 ` Patrick Schäfer @ 2009-06-30 18:38 ` Patrick Schäfer 2009-06-30 18:46 ` Andrew Haley 1 sibling, 1 reply; 11+ messages in thread From: Patrick Schäfer @ 2009-06-30 18:38 UTC (permalink / raw) To: java 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Howto: Profiling GCJ code? 2009-06-30 18:38 ` Patrick Schäfer @ 2009-06-30 18:46 ` Andrew Haley 0 siblings, 0 replies; 11+ messages in thread From: Andrew Haley @ 2009-06-30 18:46 UTC (permalink / raw) To: Patrick Schäfer; +Cc: java 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2009-06-30 18:46 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-06-19 8:52 Howto: Profiling GCJ code? Patrick Schäfer 2009-06-19 9:47 ` Bryce McKinlay 2009-06-22 13:35 ` Ian Rogers 2009-06-22 19:25 ` Patrick Schäfer 2009-06-22 22:50 ` Bryce McKinlay 2009-06-22 22:53 ` Andrew Pinski 2009-06-26 13:15 ` Patrick Schäfer 2009-06-29 4:54 ` Boehm, Hans 2009-06-30 18:21 ` Patrick Schäfer 2009-06-30 18:38 ` Patrick Schäfer 2009-06-30 18:46 ` Andrew Haley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).