This is the mail archive of the
java-discuss@sourceware.cygnus.com
mailing list for the Java project.
Re: interface dispatch
- To: per at bothner dot com (Per Bothner)
- Subject: Re: interface dispatch
- From: Godmar Back <gback at cs dot utah dot edu>
- Date: Sat, 23 Oct 1999 13:23:08 -0600 (MDT)
- Cc: gback at cs dot utah dot edu, java-discuss at sourceware dot cygnus dot com
>
> > On another note regarding the size of the ioffset tables, how would you
> > deal with
> > invokeinterface InterfaceMethodRef(InterfaceType, "equals")
> > instructions?
> >
> > If you adopted the assumption that java.lang.Object is an interface
>
> Why? Object is a class. My assumption was that class inheritance
> and virtual calls would be handled using a simpler and faster scheme
> than what you use for interfaces.
It may be trivial, but I just wanted to point out that you have to
recognize that case in your compiler in order to identify cases where
you can synthesize a virtual call out of an invokeinterface instruction.
It won't work to blindly apply the interface dispatch scheme whenever you
see an invokeinterface instruction in the bytecode.
In an earlier discussion, I pointed out that the correct way to compile
interface A {}
f(A x) {
x.equals(...)
}
is by using "invokeinterface" as opposed to "invokevirtual", and that the
correct run-time semantics is
checkcast A
invokevirtual "equals"
Basically, all I meant to say is that the compiler needs to identify
such instances of invokeinterface to which the faster scheme can be
applied.
- Godmar