Re: Eclipse 3.0

[Robert Lougher]

Hi,

Apologies for my previous rather vacuous reply.  Gmail doesn't seem to be 
receiving classpath ATM(or very slowly), so I replied to Jeroen's email, 
without realising there was rather more to it...

My observations follows what Eric has said.  Using javac 1.3 and jikes I saw 
a call to (say) toString on an interface converted to invokevirtual, but 
compiled as invokeinterface if toString was redeclared.  On javac 1.4, it 
was converted to invokevirtual regardless.

However, you can end up with the situation where you have an invokeinterface 
to toString when it hasn't been redeclared by separate compilation.  
Redeclare it in the interface, compile the user class, remove it from the 
interface and only recompile the interface.  As Eric said, a VM should be 
robust in this situation.

Of course, this isn't the situation with Eclipse.  The method _was_ 
redeclared in a super-interface hence it compiles to invokeinterface.  
However, interface method resolution in JamVM found the method on Object 
before looking for it in the super-interfaces.  This is probably a bug, but 
the fix fixes this and the robustness case.  I presume in the case of the 
JLS, it is more correct not to flatten if it is redeclared, but from a VM 
point of view, invokevirtual is faster.

Rob.

----Original Message Follows----
From: Eric Blake <address@hidden>
To: Jeroen Frijters <address@hidden>
CC: Mark Wielaard <address@hidden>, address@hidden
Subject: Re: Eclipse 3.0
Date: Tue, 06 Jul 2004 07:32:17 -0600

Jeroen Frijters wrote:
> Eric Blake wrote:
>
> I think you two are talking about two different things. I think Robert
> means that it is legal to use invokeinterface on an Object method
> through an interface type. So this is legal:
>
>   invokeinterface java/lang/Runnable/toString()Ljava/lang/String;

No, it is the same issue.  The compiler must always allow you to invoke a 
public method from Object from a qualifying type of an interface (since in 
JLS 9, interfaces implicitly have all public methods from Object), but the 
compiler's responsibility according to JLS 13.1 is to flatten that to a call 
on Object if and only if the qualifying type does not redeclare (or inherit 
a redeclaration) of the method.  Corallary - since no interface can 
redeclare a final method, a compiler should never produce invokeinterface 
SomeInterface.getClass or any of the other final methods in Object; so this 
issue only affects equals, hashCode, and toString.

class Foo
  {
  void m(Runnable r, java.util.Collection c)
  {
    r.toString(); // compiler must flatten to invokevirtual 
Object.toString: Runnable does not redeclare toString
    c.equals(r); // compiler must emit invokeinterface Collection.equals: 
since Collection redeclares equals
  }
}

However, there are buggy compilers out there that emit invokeinterface 
Runnable.toString(), even though Runnable does not redeclare toString; and a 
robust JVM implementation will be prepared to deal with this situation.

This is a binary compatibility issue - in other words, it is possible to 
expose javac 1.4's bug by using inconsistent .class files to show whether a 
class was compiled with a call invokevirtual Object.toString or 
invokeinterface SomeInterface.toString (and the jacks compiler test suite 
does this).


> Regards,
> Jeroen

--
Someday, I might put a cute statement here.

Eric Blake             address@hidden


_______________________________________________
Classpath mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/classpath

_________________________________________________________________
Use MSN Messenger to send music and pics to your friends 
http://www.msn.co.uk/messenger