Boxing, still a limit of invokedynamic?
blackdrag at gmx.org
Sun May 13 09:04:51 PDT 2012
I wanted to ask you of your opinion. If I am going to compile something
like a+b-c and a,b,c are all primtives, but I won't know that the
results will be really the primtives too, then this means I will most
probably compile it like this:
invokedynamic("minus", invokedynamic("plus",a,b), c)
meaning the result of a+b will be an Object (since I won't know it is a
primitive) and then there will be one boxing for that, just to unbox
again for the minus and then box again for the result of the minus. If
now the result is not supposed to be a primitive, then there won't be
another unbox, till the next operation done with that value.
Now, even if the JIT is able to see through the one boxing and unboxing
fro the result of plus, what will stay is the boxing for the result of
the minus.... plus the many unboxing actions used when this result is
used. Isn't that a conceptual problem? And how do others deal with that?
I am asking because I was experimenting with method signatures and for
such plus and minus methods and got mixed results. I was expecting the
primtive versions would achieve the best results, but that was not the
case. a plus(int, int) had worse performance than a plus(int,Integer) or
plus(Integer,int) in some cases and sometimes it looked like
plus(Integer,Integer) is worse, in other cases not. Well, this is
causing me some problems. Why do I get such strange results? I would
assume it depends on the JIT and the boxing logic it is able to
recognize and not.
One more thing I noticed is, that if I have a = b+c, with all of them
being int and b+c returning object, then letting the MethodHandle do the
conversion from Object to int is actually much worse performance wise,
than a cast to integer and calling valueOf. Shouldn't that be at least
equal, if not fast considering that the result of b+c was first boxed
and then is unboxed?
Can anyone give me some advice on how to do these things?
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org
More information about the mlvm-dev