class initialization check overhead
Mon Nov 25 21:53:00 GMT 2002
>>>>> "Jeff" == Jeff Sturm <email@example.com> writes:
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.
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.)
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.
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
More information about the Java