This is the mail archive of the
mailing list for the Java project.
Re: Initial profiling results (was: Re: -O2 loop problems)
- To: jeff dot sturm at commerceone dot com
- Subject: Re: Initial profiling results (was: Re: -O2 loop problems)
- From: Bryce McKinlay <bryce at albatross dot co dot nz>
- Date: Fri, 05 Jan 2001 13:19:42 +1300
- CC: tromey at redhat dot com, "'java-discuss at sources dot redhat dot com'" <java-discuss at sources dot redhat dot com>
- References: <Pine.LNX.firstname.lastname@example.org> <email@example.com> <3A55067C.49D34503@appnet.com>
Jeff Sturm wrote:
> (Anybody else seeing weird memory corruption from iconv? It could be a platform
> bug, or a 64-bit thing.)
When I upgraded to Red Hat's latest glibc 2.2-9 RPM (which isn't even glibc 2.2,
its a newwer snapshot from cvs), gcj broke with what looked like iconv problems -
it started seeing blocks of garbage characters in the middle of source files. I
rolled back the glibc and it went fine again.
> _Jv_FindArrayClass__FPQ34java4lang5Cla 5620 2.5
> _Jv_FindClassInCache__FP13_Jv_Utf8Cons 2847 1.2
> I wouldn't have guessed that _Jv_FindArrayClass is hit so hard. It also
> surprises me that so many cycles are spent in _Jv_AllocObject, which doesn't do
> much besides call the GC allocator.
Wow, I hadn't really thought about it either. I think we can speed this up very
easily. It needs to be made smaller and inline, with a new _Jv_CreateArrayClass to
be called only when the array class hasn't been created already.
Also, is there a reason why we don't add an "arraytype" field to all class objects
and cache the associated array type in it? Currently it has to craft the classname
and look it up in a cache on every non-primitive array allocation. Slow!
> _Jv_AllocObject 5487 2.4
> _Jv_AllocObj__FiPQ34java4lang5Class 2809 1.2
Hans's thread local allocation stuff should help to make this quicker, and also we
hope to shorten the allocation path by inlining the GC's allocation functions.
> _Jv_CheckArrayStore 5062 2.2
Eventually, this will hopefully disappear completely, once we inline type checks...
> _Jv_InitClass 3661 1.6
... and ditto for initialization tests.
> I'd love to know how to get at similar hardware event counters on x86. I'm not
> familiar with any free tools for that arch. Since I can't do reasonable-cost
> multithreaded profiling in software, I'm sticking with Iprobe on Alpha.
Have you tried gprof with a recent glibc? I read a post where Andreas Jaeger
claimed that it should work with threads now, but I havn't tried a profiled build
> (Sorry about the long post. This is perhaps far more detail than you expected,
> and I've just hit the tip of the iceberg. The real fun is figuring out how to
> interpret the data. I'll keep you posted on any unusual results.)
_very_ interesting... thanks!
[ bryce ]