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

[Jeff Sturm <jsturm at detroit dot appnet dot com>]

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