RE: Fibonacci and performance

[Jeff Sturm <jsturm at one-point dot com>]

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

I think AG is describing something else.  His method-local flag serves to
eliminate redundant calls to _Jv_InitClass at compile time.  Your example
is a flag of class scope which can change asynchronously, so it must have
volatile semantics, but may prevent unneeded function calls at runtime.

It seems to me that both optimizations have merit, and are not in
conflict with each other...

> Somehow the backend should know that the flag may asynchronously change to
> true, but it can't ever change back to false.  Is there a way of telling
> it that?

Wrap the volatile test in the local test, so the compiler can eliminate it
when possible?  That sounds clumsy but it seems like it ought to work.

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

Jeff