Invokedynamic and recursive method call

[Marcus Lagergren]

7u40 is when the native invoke dynamic implementation was replaced with Lambda Forms :-/

/M

> On 07 Jan 2015, at 17:13, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> 
> On 01/07/2015 10:43 AM, Marcus Lagergren wrote:
>> Remi, I tried to reproduce your problem with jdk9 b44. It runs decently fast.
> 
> yes, nashorn is fast enough but it can be faster if the JIT was not doing something stupid.
> 
> When the VM inline fibo, because fibo is recursive, the recursive call is inlined only once,
> so the call at depth=2 can not be inlined but should be a classical direct call.
> 
> But if fibo is called through an invokedynamic, instead of emitting a direct call to fibo,
> the JIT generates a code that push the method handle on stack and execute it
> like if the metod handle was not constant
> (the method handle is constant because the call at depth=1 is inlined !).
> 
>> When did it start to regress?
> 
> jdk7u40, i believe.
> 
> I've created a jar containing some handwritten bytecodes with no dependency to reproduce the issue easily:
>  https://github.com/forax/vmboiler/blob/master/test7/fibo7.jar <https://github.com/forax/vmboiler/blob/master/test7/fibo7.jar>
> 
> [forax at localhost test7]$ time /usr/jdk/jdk1.9.0/bin/java -cp fibo7.jar FiboSample
> 1836311903
> 
> real    0m6.653s
> user    0m6.729s
> sys    0m0.019s
> [forax at localhost test7]$ time /usr/jdk/jdk1.8.0_25/bin/java -cp fibo7.jar FiboSample
> 1836311903
> 
> real    0m6.572s
> user    0m6.591s
> sys    0m0.019s
> [forax at localhost test7]$ time /usr/jdk/jdk1.7.0_71/bin/java -cp fibo7.jar FiboSample
> 1836311903
> 
> real    0m6.373s
> user    0m6.396s
> sys    0m0.016s
> [forax at localhost test7]$ time /usr/jdk/jdk1.7.0_25/bin/java -cp fibo7.jar FiboSample
> 1836311903
> 
> real    0m4.847s
> user    0m4.832s
> sys    0m0.019s
> 
> as you can see, it was faster with a JDK before jdk7u40.
> 
>> 
>> Regards
>> Marcus
> 
> cheers,
> Rémi
> 
>> 
>>> On 30 Dec 2014, at 20:48, Remi Forax <forax at univ-mlv.fr> wrote:
>>> 
>>> Hi guys,
>>> I've found a bug in the interaction between the lambda form and inlining algorithm,
>>> basically if the inlining heuristic bailout because the method is recursive and already inlined once,
>>> instead to emit a code to do a direct call, it revert to do call to linkStatic with the method
>>> as MemberName.
>>> 
>>> I think it's a regression because before the introduction of lambda forms,
>>> I'm pretty sure that the JIT was emitting a direct call.
>>> 
>>> Step to reproduce with nashorn, run this JavaScript code
>>> function fibo(n) {
>>>  return (n < 2)? 1: fibo(n - 1) + fibo(n - 2)
>>> }
>>> 
>>> print(fibo(45))
>>> 
>>> like this:
>>>  /usr/jdk/jdk1.9.0/bin/jjs -J-XX:+UnlockDiagnosticVMOptions -J-XX:+PrintAssembly fibo.js > log.txt
>>> 
>>> look for a method 'fibo' from the tail of the log, you will find something like this:
>>> 
>>>  0x00007f97e4b4743f: mov    $0x76d08f770,%r8   ;   {oop(a 'java/lang/invoke/MemberName' = {method} {0x00007f97dcff8e40} 'fibo' '(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;I)I' in 'jdk/nashorn/internal/scripts/Script$Recompilation$2$fibo')}
>>>  0x00007f97e4b47449: xchg   %ax,%ax
>>>  0x00007f97e4b4744b: callq  0x00007f97dd0446e0
>>> 
>>> I hope this can be fixed. My demonstration that I can have fibo written with a dynamic language
>>> that run as fast as written in Java doesn't work anymore :(
>>> 
>>> cheers,
>>> Rémi
>>> 
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net <mailto:mlvm-dev at openjdk.java.net>
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev <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/20150107/0c290f62/attachment-0001.html>