performance degeneration from jdk7u2 to jdk7u6?

Jochen Theodorou blackdrag at gmx.org
Wed May 30 14:16:48 PDT 2012


Am 24.05.2012 13:43, schrieb Rémi Forax:
[...]
> if invokedynamic knows more, you can provide a path with
> less boxing so it's usually better.

  I changed Groovy to get rid of getCallSiteArray and added 
backpropagation of the return type to the next directly involved method 
call. So in

int fib(int x) {
     if (x<=1) return 1
     return fib(x-1)+fib(x-2)
}

the plus will now have directly return type int, instead of Object.

In a first iteration I made a primitives taking minus method, that also 
returns int. And nice, runtime is down from 3.5 (on update 2) to 2.5 (no 
tiered compilation and update 6).

That is not yet making really use of the type back propagation, so in 
the next iteration I added a (II)I plus method as well. Before the 
callsite target type was (II)Object, now it is (Object,Object)I, so only 
little I can save on boxing, but let us see... 2.1s! And it stabilizes 
much faster than before too. That's almost as much gain as before (in 
percent). Certainly more than I thought.

Had I only used the plus method and not the minus method as well, I 
would have ended up with 4.2s. only both together do make it that fast 
now. A behaviour I noticed with primitive optimizations as well. An 
optimization done in isolation can make things slower or does show only 
little gain, but in combination they are suddenly much better. Another 
interesting aspect is, now I don't see the slowdown through tiered 
compilation anymore. The times are more or less equal with and without 
tiered compilation, while before it was always slower with tiered 
compilation not disabled (in update 6 it is on by default).

So the current state of my fib program is:

indy: 2.1s
primopts: 1.2s
callsite caching: 4s

Now I know that using catchException is causing quite a problem for 
indy, so I removed that guard for the math operations plus and minus. It 
is legal, since in those cases I can be certain I don't need it. And now 
indy is at 1.2s! That means primopts and indy are no on par. That's very 
cool! I mean I expected indy to come near indy, but to actually get on 
par with it... I would never have thought that is possible.

The assembly is still quite big: http://rifers.org/paste/show/1717
But much better already.

bye Jochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org



More information about the mlvm-dev mailing list