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
_______________________________________________
mlvm-dev mailing list
[email protected]
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev