Virtual extension methods -- second draft

[Rémi Forax]

Le 08/06/2010 15:14, Brian Goetz a écrit :
> I've updated the draft on Defender Methods:
>     http://cr.openjdk.java.net/~darcy/DefenderMethods.pdf
>    

Hi Brian,

7: implementation 1:
Superclass is not loaded before subclass.
when subclass is loaded, it trigger the loading of the super class.
But the vtable of the superclass is created before the vtable of the 
subclass.

8: I see two problems with the invokedynamic approach.
invokedynamic is a callsite resolution but here all call sites will be 
resolved in the same way,
so using invokedynamic is a waste of CPU cycles.
You need a way to transfer the information stored from the bytecode 
attribute of
the defender method to the bootstrap method.
The JSR 292 doesn't provide any mechanism for doing that.
There is a solution based on mangling the defender information with the name
used by the invokedynamic bytecode but this means that if the defender 
information changed,
all callsites must be recompiled wich is not a desirable property.

Brian, I don't understand why you don't want to let the VM adds the 
defender methods
when the vtable is created during the linking time.

Rémi

> On 5/14/2010 7:16 PM, Brian Goetz wrote:
>    
>> The attached document reflects our current thinking in the area of
>> extension methods, which was introduced in section 8 of the Strawman
>> proposal. This document (arguably) improves on the static extension
>> method scheme presented there.
>>
>> Comments on the technical merits and flaws of the scheme are welcome
>> (there are lots of details to be fleshed out, of course.) Comparisons to
>> the previous (static) extension method scheme outlined in the strawman
>> are also fair game.
>>
>> Comments to the effect of "I like XYZ other scheme better" are not.
>> (Where XYZ could be use-site extension methods, traits, mixins, etc.
>> Those have already been considered and rejected as viable approaches for
>> Project Lambda.)
>>
>>
>>
>>
>>      
>