Howto: Profiling GCJ code?
Patrick Schäfer
ps@ekse.de
Fri Jun 26 13:15:00 GMT 2009
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
More information about the Java
mailing list