This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: class initialization check overhead
- From: Tom Tromey <tromey at redhat dot com>
- To: shudo at computer dot org
- Cc: java at gcc dot gnu dot org
- Date: 25 Nov 2002 23:09:02 -0700
- Subject: Re: class initialization check overhead
- References: <86fzuv14ry.fsf@nowhere.com><Pine.LNX.4.44.0210250837420.10611-100000@ops2.one-point.com><20021030.234903.628180006.shudo@localhost>
- Reply-to: tromey at redhat dot com
>>>>> ">" == shudo <shudo@computer.org> writes:
>> | Method void main(java.lang.String[])
>> | 0 aconst_null
>> | 1 astore_1
>> | 2 aload_1
>> | 3 invokespecial #3 <Method java.lang.Object()>
>> | 6 return
>> Sun's Java 2 SE 1.4.1 throws java.lang.VeifyError and
Interesting. This makes sense, too.
At first I thought it didn't, but as `null' is not an "uninitialized
object", it seems that this must fail to verify.
I'm going to check this in to the Mauve verification test suite.
This case doesn't really impact class initialization though.
It might make sense to elide calls to superclass constructors in some
situations. Unfortunately binary compatibility rears its head here as
well. Still, in the meantime it may be a useful optimization.
Anybody care to find out?
Tom