Trying to work newer indy into JRuby

[Rémi Forax]

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 at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>