From: "Patrick Schäfer" <ps@ekse.de>
To: "Boehm, Hans" <hans.boehm@hp.com>
Cc: java@gcc.gnu.org
Subject: Re: Howto: Profiling GCJ code?
Date: Tue, 30 Jun 2009 18:21:00 -0000 [thread overview]
Message-ID: <A1669A9E-58AF-4868-BB72-D55AB392EDD9@ekse.de> (raw)
In-Reply-To: <238A96A773B3934685A7269CC8A8D0424DFBCAFA87@GVW0436EXB.americas.hpqcorp.net>
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
>>
>>
next prev parent reply other threads:[~2009-06-30 18:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-19 8:52 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 [this message]
2009-06-30 18:38 ` Patrick Schäfer
2009-06-30 18:46 ` Andrew Haley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=A1669A9E-58AF-4868-BB72-D55AB392EDD9@ekse.de \
--to=ps@ekse.de \
--cc=hans.boehm@hp.com \
--cc=java@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).