Re: Patch (please comment): class loader and interpreter fixes

[Tom Tromey <tromey at redhat dot com>]

Eric> I'm not the best to speak when it comes to gcj internals, but
Eric> here are some views based on a spec standpoint.

I was hoping you'd reply.

Eric> This should also work.  Maybe a different name is in order, like
Eric> ACC_INVISIBLE? You don't want anyone thinking that the Synthetic
Eric> attribute in the .class file and your new ACC_SYNTHETIC access
Eric> flag are synonyms

Thanks.  I had forgotten about the Synthetic attribute.
I'll make this change.

>> * This fixes the vtable layout code to correctly handle final
>> classes -- a new method in a final class doesn't get a vtable slot.
>> Also, we put a special function into "abstract" vtable slots, just
>> in case.

Eric> Will this make it possible to simplify code elsewhere?

I think in the past we already made this assumption.  This is
something that changed a bit with a vtable cleanup patch Jeff checked
in a while back.  I'll go through and make sure though.

Eric> However, there is one problem I just ran across -- you also need to
Eric> worry about inherited interface fields:

Thanks.  I was only dimly aware of this.  I'll add this to my list --
but if you want to submit a PR for this, that would be helpful.

Eric> But gcj always emits the incorrect code; should I file a bug
Eric> against gcj for being non-compliant, since gcj doesn't support
Eric> -source yet?

Yes, thanks.

gcj doesn't handle Miranda methods correctly.  I think there's a PR on
this.  And anyway it fails a few Jacks tests in this area.  (Basically
we need somebody to just fix gcj Jacks failures full time.  I wish.)

Eric> Anyways, is it possible to do the same trick for fields as for
Eric> Miranda methods?  Since I.i is final, you could create a
Eric> synthetic field C.i and copy the value of i there once it is
Eric> known.  But I am wondering about initialization semantics - will
Eric> code always see the semantically correct value of C.i, no matter
Eric> what code path is taken?

The reason this approach was simpler for methods wasn't due to lookup
of the method at runtime, but instead because it made vtable
construction simpler.  Finding a given method name in the hierarchy is
not a big problem.  The problem comes when building the vtable for a
subclass of an abstract class that has Miranda methods -- in this case
we'd need to do a complete lookup for every method in all the
interfaces implemented (directly or indirectly) by the abstract class.
It seemed simpler to just do this once per abstract class instead.

I think for fields we can just change it to do the full lookup.  For
the direct-threaded interpreter we'll only do this lookup once for a
given piece of bytecode anyway.

Tom