class initialization check overhead

[Jeff Sturm]

On 25 Nov 2002, Tom Tromey wrote:
> Jeff> Come to think of it... what if compiled classes were prepared
> Jeff> early instead of at initialization time?  In my application of
> Jeff> 191 classes, only 36 have a <clinit>.  If the frontend knows
> Jeff> that a class invokes no <clinit> method (directly or in a
> Jeff> superclass), could the _Jv_InitClass be dropped entirely?
>
> Yes, with caveats.
>
> I think there are two cases to consider.
>
> First, the general case.  Once we have the full binary compatibility
> code in place, we won't be able to omit class initialization calls.

I agree.  For full binary compatibility, I'd eventually like
-fno-assume-compiled and -findirect-dispatch to work together.  Entire
packages could be compiled to native code with direct references to
classes in the same package, while assuming nothing about other packages.

I think that could yield a good compromise of optimization and
compatibility.

> However, we'll probably still have support for things like "treat
> package X as a unit".  In this case no-op initializations within that
> package could be omitted.  (Note that we probably won't want people to
> treat libgcj this way, since one goal is to get binary compatibility
> for applications across releases.)

Yes.  Libgcj should be free to optimize within its boundaries, however.

> With binary compatibility, though, we have a second approach.  In this
> mode all static calls will go through a vtable-like object (I think it
> is called the otable).  In this mode we can set up the static method
> otable slots to point to a class initialization trampoline.  Then we
> can reset these slots after initialization has completed (or point
> them at an error-throwing function if initialization fails).  I think
> of it as self-modifying code or as methods with two entry points.

I was thinking external field/method references would go through the
class constant pool, as is done for the interpreter.  _Jv_ResolvePoolEntry
has much of the needed code for JV_CONSTANT_Methodref and
JV_CONSTANT_Fieldref cases now.

> This sacrifices some optimization, though, since the compiler won't be
> able to assume that an otable slot is constant.  (BTW does gcj
> currently know that vtable slots are immutable?  In the past I think I
> looked at this and decided it didn't know and was therefore missing
> some potential optimizations.  But I haven't looked in quite some
> time.)

I noticed that too.  I guess the backend considers all memory to be
clobbered by a call, even expressions marked with TREE_READONLY or
TREE_CONSTANT.  There must be some way to tell the backend that the
value at some address will never change.  But I didn't investigate very
long.

Jeff