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.

-- John
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Reply via email to