PR 13948 and Miranda Methods

[Bryce McKinlay]

Ranjit Mathew wrote:

>>Ranjit>   2. Miranda methods are needed to work with older buggy VMs
>>Ranjit>      that need an implicit method declaration in an abstract
>>Ranjit>      class for a method from an implemented interface (right?).
>>
>>An abstract class isn't required to declare methods inherited from
>>interfaces.  However, when we build vtables these methods have to
>>come from somewhere.  So, we introduce these fake Miranda methods to
>>make vtable construction work out right.  We do this in the compiler
>>when generating .o files and in the runtime for other classes.  So,
>>it isn't a compatibility thing -- it is really needed.
>>    
>>
>
>I'm not totally sure, but can't this be treated in the way that
>multiple inheritance is in the C++ ABI? (Of which I know zilch,
>so never mind...)
>  
>

MI is basically implemented in C++ by sticking the vtables of your 
superclasses together and twiddling the vtable pointers - its pretty 
icky and I don't think it would solve any problems - Java interfaces 
don't have vtables. The "miranda methods" problem is just a matter of 
making sure that methods implicitly inherited from interfaces in an 
abstract class get vtable slots. Note that the issue only applies to the 
current ABI - the problem dissapears with the BC-ABI.

>>Ranjit>      However, layout_class_methods() calls add_miranda_methods()
>>Ranjit>      anyways - so isn't the call on line 2097 made redundant by his
>>Ranjit>      patch?
>>
>>I don't know, but it would appear so.
>>    
>>
>
>Hmmm... Bryce/Andrew - what're your thoughts on this?
>
>I removed that line (i.e. 2097 in class.c) and recompiled
>libjava and ran the testsuite (including Jacks), without
>any regressions. Would anyone have any objections to
>removing it?
>  
>

No objections here, I think you're right - the add_miranda_methods 
recursive call is redundant because layout_class_methods() calls it anyway.

Regards

Bryce