Arg ordering on the test path method handle for GwT

[Mark Roos]

My goal was to do the port at the byte code level so that there would be a 
high degree of confidence
that the 500K of existing code will work as it does today.  It is a stack 
based VM so changing the arg
order could add some pain for me (another thing I try to avoid).   Since I 
am not calling Java methods
the order is consistent within the Smalltalk world so the only rough spot 
is in guard with test.

I was thinking of either permute (just move one arg), drop or collect. All 
would need to be specific for
a given airity.  Since this is for the test path of guard with test the 
args are discarded so it seems any
of the above would work.  Any thoughts on which might be the least 
overhead? ( or best optimized?).
I was guessing permute ( as you suggested)

thanks

mark















On 01/06/2011 05:42 PM, Mark Roos wrote: 
Thanks to all for the suggestions on providing live constants to a method. 


I must admit that I was impressed with how the constant patch approach 
worked. 
As my constants are defined using an utf8 string it was easy to use some 
unused 
constant type tags to mark my constants.  The loader then searched for 
them, 
created a patch from the string and then converted the tag to the utf8 
tag. 
Load the class and done.  Very nice. 

But I was worried that this was not mainstream.  So Remi's inputs were 
good. 
My first attempt was ugly.  Ugly in that the constant pool went wild.  For 
each 
constant ( and a method could have a hundred or so ) I needed an 
invokeDynamic, 
a bootstrap table entry and my constant string.  After thinking a bit ( 
always a 
good thing to try) I realized that the name part of the invoke dynamic 
could 
carry the constant.  So now I have a shared bootstrap, and a per constant 
invokeDynamic, 
nameAndType and constant. 

Not as pretty as the pool patching but good enough.  My only concern will 
be how well 
it gets optimized and that I will leave to the experts. 

Now on to airity and the unfortunate issue that my stack order is opposite 
that of Java 
('this' is at the end not the beginning) 

For the stack order, your bytecode generator should just generate 
arguments
in reverse order or if you're lazy, you can use 
MethodHandles.permuteArguments().


regards 
mark

Rémi
_______________________________________________
mlvm-dev mailing list
mlvm-dev at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110106/0ba4f839/attachment.html