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: Tom Tromey <tromey at redhat dot com>
- To: "Boehm, Hans" <hans_boehm at hp dot com>
- Cc: "'Per Bothner'" <per at bothner dot com>, Alexandre Petit-Bianco <apbianco at redhat dot com>, java at gcc dot gnu dot org
- Date: 30 Nov 2001 17:45:57 -0700
- Subject: Re: question about -fno-optimize-static-class-initialization
- References: <40700B4C02ABD5119F000090278766443BEDB1@hplex1.hpl.hp.com>
- Reply-to: tromey at redhat dot com
>>>>> "Hans" == Boehm, Hans <hans_boehm@hp.com> writes:
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).
Andrew used to talk about setting up static methods so they only do
class initialization once. For instance, we could call them via a
pointer, and then change the pointer to a different (non-initializing)
entry point after class init. If we did something like this we could
just apply the same idea to <init>. I have no clue whether this is
better or worse, in general, than what we do now.
Hans> (It should also pass in the vtable pointer rather than the
Hans> class, but that's presumably not hard.)
I think that's easy.
I wonder if we can get better class initialization optimization is out
of the tree optimizer work somehow.
Tom