Latest Thinking

Rémi Forax forax at univ-mlv.fr
Tue Jun 22 14:25:52 PDT 2010


Le 22/06/2010 22:46, John Rose a écrit :
> On Jun 22, 2010, at 1:32 PM, John Rose wrote:
>
>    
>> The small amount of support in javac for 292 is a low-level punch-through to allow assembly-level programming.
>>      
> A little more detail:  Here's the sort of thing I'm experimenting with, for local BSMs on invokedynamic:
>
> Object x = InvokeDynamic.<@BootstrapMethod(value=MyLinker.class, name="myBootstrap") Object>  greet(1,"two");
>
> Observations:
>
> 1. Yes, it's ugly, and by design.  It's a moral approximate to an asm statement.
>
> 2. The optional BSM data is injected via a JSR 308 type-use annotation, in the only possible place.
>
> 3. The @BootstrapMethod annotation can also go on larger program elements, providing a default for all enclosed indy.
>
> 4. With this design, we can probably get rid of registerBootstrapMethod, and use a purely declarative BSM encoding.
>
> 5. I would of course have preferred to do @BootstrapMethod(MyLinker#myBootstrap), except it's too disturbing to too many layers of the stack, for little benefit.  (As I found out when I started prototyping.)  It would be nice if the 309 EG decided to put MH literal values into the annotation schema, but if you look at their design docs, you'll see that they don't want to bite off any more design chunks that large.  It will have to be a future.
>
> A note on encoding:  The BSM data is encoded in new constant pool entries, linked from the instruction.  Despite the extra zero bytes in the instruction format, the EG does not want to "cleverly" put two indexes into one instruction.  Instead, we have something like a Methodref, but with the BSM taking the class of the class reference.
>    

There is another possible design.
Allow users to create fake types like java.dyn.Invokedynamic
and define the annotation on that type.

Example:

@BootstrapMethod(value=MyLinker.class, name="myBootstrap")

class MyInvokeDynamic { }

...
MyInvokeDynamic.<Object>greet(1, "two");


> -- John
>    

Rémi


More information about the mlvm-dev mailing list