Re: Fibonacci and performance

[Tom Tromey <tromey at redhat dot com>]

Hans> Isn't there a fundamental problem here?  The testing of the
Hans> "initialized" flag may not be reordered with respect to variable
Hans> references, and hence should be treated as volatile (and
Hans> possibly requiring a memory barrier) by the back end.  But if
Hans> it's treated as volatile, you can't optimize out redundant
Hans> tests?

Jeff> I think AG is describing something else.  His method-local flag
Jeff> serves to eliminate redundant calls to _Jv_InitClass at compile
Jeff> time.

But Hans is saying that in AG's scenario the check of the method-local
flag could be reordered with respect to access to class variables,
unless the flag is volatile.

I'm not sure this can actually happen.  The test will look like:

    if (! method-local-flag) { _Jv_InitClass (...); m-l-f = true; }

Will the compiler really pull a class variable access before this?  I
don't see how it could do that.  It seems to me that if the compiler
could do that then our current approach of always calling
_Jv_InitClass is also broken.

Jeff> There's a little problem with the local test though.  If two
Jeff> methods a() and b() may initialize the same class, and a()
Jeff> inlines a call to b(), it will end up with two local flags for
Jeff> the same class initialization.  I don't know how to get around
Jeff> that, unless inlining can be performed on the parse tree prior
Jeff> to build_class_init.

There are probably a few approaches we could take to solve this.

Maybe we could introduce our own java-specific tree code representing
class initialization, which is only expanded ("lowered") to generic
tree codes later on.

Maybe we could handle it specially when doing tree based inlining.

Tom