John Rose a écrit :
> On May 19, 2009, at 2:17 PM, Charles Oliver Nutter wrote:
>
>
>> I don't think there's going to be any more changes at the bytecode
>> level, right? Can we get this pushed into an ASM release soon?
>>
>
> Anything's possible, but I don't expect the current format to change.
>
> -- John
>
Hum, we have to decide if the two new LDC are a good idea or not.
And there is still in my opinion, a mismatch between the language compiler
type system and the requirement of MethodHandle.invoke()
even if I've no clear idea on how to solve it.
Using the BGGA syntax,
{CharSequence => CharSequence fun = { CharSequence seq => seq };
CharSequence result=fun.invoke("hello");
the code is compiled to:
static CharSequence fun(CharSequence seq) {
return seq;
}
...
MethodHandle fun=MethodHandles.convertArguments(
ThisClass#fun(CharSequence,CharSequence), // LDC
fun(LCharSequence)LCharSequence;
#Object(Object)); // LDC (LCharSequence)LCharSequence;
CharSequence result=(CharSequence)fun.<Object>invoke((Object)"hello");
type at MethoHandle.invoke: Object(Object)
type for the compiler: CharSequence(String)
I don't like that because the real signature is lost, and all possible
optimisations based on static profiling with it.
Two possible solutions:
- always compare erased signature when doing methodHandle.invoke
which means defining what erased signature means and where to store it.
- add the two signature when doing a methodHandle.invoke which means
another new bytecode.
Rémi
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
