This is the mail archive of the java-discuss@sources.redhat.com mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Initial profiling results (was: Re: -O2 loop problems)


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

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

regards

  [ bryce ]



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]