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

Fri Jan 5 10:04:00 GMT 2001

On Fri, 5 Jan 2001, Bryce McKinlay 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.

Hmm. I'm seeing iconv (or Input_iconv, or something) write over live
class objects, causing an eventual crash. I got around it by undef'ing
HAVE_ICONV. Next time I'll try to figure out if it's a problem with
libgcj or glibc.
> 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!

Sounds good to me.
> 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.

I haven't. But I prefer hardware counters when available. Code
instrumentation not only requires a recompile, but slows execution up to
30% or more. By contrast, the Alpha event counters impact performance by
2-3%, tops. I'm not an x86 expert, but I'd think it has to have similar
counters. How else do people measure things like cache hit rate
statistics?
Jeff