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@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
