This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: question about -fno-optimize-static-class-initialization
- From: Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>
- To: tromey at redhat dot com
- Cc: "Boehm, Hans" <hans_boehm at hp dot com>, "'Per Bothner'" <per at bothner dot com>, Alexandre Petit-Bianco <apbianco at redhat dot com>, java at gcc dot gnu dot org
- Date: Sat, 01 Dec 2001 14:57:57 +1300
- Subject: Re: question about -fno-optimize-static-class-initialization
- References: <40700B4C02ABD5119F000090278766443BEDB1@hplex1.hpl.hp.com> <87ofljpy2i.fsf@creche.redhat.com>
Tom Tromey wrote:
>
>Hans> How easy is it to determine whether a call to _Jv_AllocObject
>Hans> may have to initialize the class? I guess that's a different
>Hans> issue. But it's the last major problem that needs to be solved
>Hans> if want the compiled code to call the garbage collector's
>Hans> allocator directly, and I think that would be a significant
>Hans> performance win.
>
>We could have a new way to allocate an object that never calls the
>initializer. The compiler would always generate calls to this, and
>then we would hoist the initializer call into the caller. I think
>these calls are already conditional so we only call them once per
>method (at least if the optimization is enabled).
>
Yes, I don't think this would be unreasonable given we already do it for
static field access etc. We also want to emit initialization calls so
that they look something like _Jv_InitClass already does, ie
if (local_init_flag_for_class == false && __builtin_expect (class->state
== JV_STATE_DONE, false))
{
_Jv_InitClass (class);
local_init_flag_for_class = true;
}
Which I think we still dont do in most cases.
Also, the problem with using a local to keep track of the initialized
state of a class is that it potentially doesn't work across inlined
calls (ie the inlined function uses a different local, so constant
propogation cant eliminate the initialization check/call), so maybe they
should be something like:
if (__builtin_expect (class->state == JV_STATE_DONE, false))
{
_Jv_InitClass (class);
class->state == JV_STATE_DONE;
}
As long as the compiler can understand that class->state is "const"
after InitClass is called, it ought to then be able to eliminate
additional calls even if they occur in an inlined function.
Or, perhaps once we get tree based inlining, we can run a rudundant
class initialization elimination pass after the inlining is done and
avoid this issue.
regards
Bryce