Re: Invokedynamic and recursive method call

[Remi Forax]

Thank you,
Vladimir !

Rémi

On 01/30/2015 04:07 PM, Vladimir Ivanov wrote:

Remi, thanks for the report!

Filed JDK-8072008 [1].

Best regards,
Vladimir Ivanov

[1] https://bugs.openjdk.java.net/browse/JDK-8072008

On 1/30/15 4:03 AM, Remi Forax wrote:


On 01/30/2015 01:48 AM, John Rose wrote:

On Jan 7, 2015, at 8:13 AM, Remi Forax mailto:fo...@univ-mlv.fr>> wrote:


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 !).


Invocation of non-constant MH's had a performance regression with the
LF-based implementation.
As of JDK-8069591 they should be no slower and sometimes faster than
the old implementation.
— John



In my case, the method handle is constant (I think it's also the case
when you write fibo in javascript).
At depth=1, the call is correctly inlined.
At depth=2, the call is not inlined because it's a recursive call and by
default hotspot only inline recursive call once,
this is normal behavior. The bug is that instead of doing a call (using
the call assembly instruction),
the JIT pushes the method handle on stack and do an invokebasic, which
is slower.

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


___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Invokedynamic and recursive method call

[Vladimir Ivanov]

Remi, thanks for the report!

Filed JDK-8072008 [1].

Best regards,
Vladimir Ivanov

[1] https://bugs.openjdk.java.net/browse/JDK-8072008

On 1/30/15 4:03 AM, Remi Forax wrote:


On 01/30/2015 01:48 AM, John Rose wrote:

On Jan 7, 2015, at 8:13 AM, Remi Forax mailto:fo...@univ-mlv.fr>> wrote:


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 !).


Invocation of non-constant MH's had a performance regression with the
LF-based implementation.
As of JDK-8069591 they should be no slower and sometimes faster than
the old implementation.
— John



In my case, the method handle is constant (I think it's also the case
when you write fibo in javascript).
At depth=1, the call is correctly inlined.
At depth=2, the call is not inlined because it's a recursive call and by
default hotspot only inline recursive call once,
this is normal behavior. The bug is that instead of doing a call (using
the call assembly instruction),
the JIT pushes the method handle on stack and do an invokebasic, which
is slower.

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

Re: Invokedynamic and recursive method call

[Remi Forax]

On 01/30/2015 01:48 AM, John Rose wrote:
On Jan 7, 2015, at 8:13 AM, Remi Forax > wrote:


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 !).


Invocation of non-constant MH's had a performance regression with the 
LF-based implementation.
As of JDK-8069591 they should be no slower and sometimes faster than 
the old implementation.

— John



In my case, the method handle is constant (I think it's also the case 
when you write fibo in javascript).

At depth=1, the call is correctly inlined.
At depth=2, the call is not inlined because it's a recursive call and by 
default hotspot only inline recursive call once,
this is normal behavior. The bug is that instead of doing a call (using 
the call assembly instruction),
the JIT pushes the method handle on stack and do an invokebasic, which 
is slower.


Rémi

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Invokedynamic and recursive method call

[Christian Thalinger]

> On Jan 29, 2015, at 4:48 PM, John Rose  wrote:
> 
> On Jan 7, 2015, at 8:13 AM, Remi Forax  > wrote:
>> 
>> 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 !).
> 
> Invocation of non-constant MH's had a performance regression with the 
> LF-based implementation.
> As of JDK-8069591 they should be no slower and sometimes faster than the old 
> implementation.

Maybe but what Remi is saying that the MH is constant and we could emit a 
direct call.

> — John
> 
> ___
> 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

Re: Invokedynamic and recursive method call

[John Rose]

On Jan 7, 2015, at 8:13 AM, Remi Forax  wrote:
> 
> 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 !).

Invocation of non-constant MH's had a performance regression with the LF-based 
implementation.
As of JDK-8069591 they should be no slower and sometimes faster than the old 
implementation.
— John

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Invokedynamic and recursive method call

[Christian Thalinger]

Trying to remember compiler implementation details this sounds reasonable and 
is a bug (or an enhancement, actually ;-).  Can someone file a bug?

> On Jan 7, 2015, at 10:07 AM, Charles Oliver Nutter  
> wrote:
> 
> This could explain performance regressions we've seen on the
> performance of heavily-recursive algorithms. I'll try to get an
> assembly dump for fib in JRuby later today.
> 
> - Charlie
> 
> On Wed, Jan 7, 2015 at 10:13 AM, Remi Forax  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
>> 
>> [forax@localhost test7]$ time /usr/jdk/jdk1.9.0/bin/java -cp fibo7.jar
>> FiboSample
>> 1836311903
>> 
>> real0m6.653s
>> user0m6.729s
>> sys0m0.019s
>> [forax@localhost test7]$ time /usr/jdk/jdk1.8.0_25/bin/java -cp fibo7.jar
>> FiboSample
>> 1836311903
>> 
>> real0m6.572s
>> user0m6.591s
>> sys0m0.019s
>> [forax@localhost test7]$ time /usr/jdk/jdk1.7.0_71/bin/java -cp fibo7.jar
>> FiboSample
>> 1836311903
>> 
>> real0m6.373s
>> user0m6.396s
>> sys0m0.016s
>> [forax@localhost test7]$ time /usr/jdk/jdk1.7.0_25/bin/java -cp fibo7.jar
>> FiboSample
>> 1836311903
>> 
>> real0m4.847s
>> user0m4.832s
>> sys0m0.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  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:
 
  0x7f97e4b4743f: mov$0x76d08f770,%r8   ;   {oop(a
 'java/lang/invoke/MemberName' = {method} {0x7f97dcff8e40} 'fibo'
 '(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;I)I' in
 'jdk/nashorn/internal/scripts/Script$Recompilation$2$fibo')}
  0x7f97e4b47449: xchg   %ax,%ax
  0x7f97e4b4744b: callq  0x7f97dd0446e0
 
 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@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
>> 
>> 
>> ___
>> 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

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Invokedynamic and recursive method call

[Charles Oliver Nutter]

This could explain performance regressions we've seen on the
performance of heavily-recursive algorithms. I'll try to get an
assembly dump for fib in JRuby later today.

- Charlie

On Wed, Jan 7, 2015 at 10:13 AM, Remi Forax  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
>
> [forax@localhost test7]$ time /usr/jdk/jdk1.9.0/bin/java -cp fibo7.jar
> FiboSample
> 1836311903
>
> real0m6.653s
> user0m6.729s
> sys0m0.019s
> [forax@localhost test7]$ time /usr/jdk/jdk1.8.0_25/bin/java -cp fibo7.jar
> FiboSample
> 1836311903
>
> real0m6.572s
> user0m6.591s
> sys0m0.019s
> [forax@localhost test7]$ time /usr/jdk/jdk1.7.0_71/bin/java -cp fibo7.jar
> FiboSample
> 1836311903
>
> real0m6.373s
> user0m6.396s
> sys0m0.016s
> [forax@localhost test7]$ time /usr/jdk/jdk1.7.0_25/bin/java -cp fibo7.jar
> FiboSample
> 1836311903
>
> real0m4.847s
> user0m4.832s
> sys0m0.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  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:
>>>
>>>   0x7f97e4b4743f: mov$0x76d08f770,%r8   ;   {oop(a
>>> 'java/lang/invoke/MemberName' = {method} {0x7f97dcff8e40} 'fibo'
>>> '(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;I)I' in
>>> 'jdk/nashorn/internal/scripts/Script$Recompilation$2$fibo')}
>>>   0x7f97e4b47449: xchg   %ax,%ax
>>>   0x7f97e4b4744b: callq  0x7f97dd0446e0
>>>
>>> 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@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
>
>
> ___
> 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

Re: 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  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 
> 
> 
> [forax@localhost test7]$ time /usr/jdk/jdk1.9.0/bin/java -cp fibo7.jar 
> FiboSample
> 1836311903
> 
> real0m6.653s
> user0m6.729s
> sys0m0.019s
> [forax@localhost test7]$ time /usr/jdk/jdk1.8.0_25/bin/java -cp fibo7.jar 
> FiboSample
> 1836311903
> 
> real0m6.572s
> user0m6.591s
> sys0m0.019s
> [forax@localhost test7]$ time /usr/jdk/jdk1.7.0_71/bin/java -cp fibo7.jar 
> FiboSample
> 1836311903
> 
> real0m6.373s
> user0m6.396s
> sys0m0.016s
> [forax@localhost test7]$ time /usr/jdk/jdk1.7.0_25/bin/java -cp fibo7.jar 
> FiboSample
> 1836311903
> 
> real0m4.847s
> user0m4.832s
> sys0m0.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  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:
>>> 
>>>  0x7f97e4b4743f: mov$0x76d08f770,%r8   ;   {oop(a 
>>> 'java/lang/invoke/MemberName' = {method} {0x7f97dcff8e40} 'fibo' 
>>> '(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;I)I' in 
>>> 'jdk/nashorn/internal/scripts/Script$Recompilation$2$fibo')}
>>>  0x7f97e4b47449: xchg   %ax,%ax
>>>  0x7f97e4b4744b: callq  0x7f97dd0446e0
>>> 
>>> 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@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
> 
> ___
> 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

Re: Invokedynamic and recursive method call

[Remi Forax]

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

[forax@localhost test7]$ time /usr/jdk/jdk1.9.0/bin/java -cp fibo7.jar 
FiboSample

1836311903

real0m6.653s
user0m6.729s
sys0m0.019s
[forax@localhost test7]$ time /usr/jdk/jdk1.8.0_25/bin/java -cp 
fibo7.jar FiboSample

1836311903

real0m6.572s
user0m6.591s
sys0m0.019s
[forax@localhost test7]$ time /usr/jdk/jdk1.7.0_71/bin/java -cp 
fibo7.jar FiboSample

1836311903

real0m6.373s
user0m6.396s
sys0m0.016s
[forax@localhost test7]$ time /usr/jdk/jdk1.7.0_25/bin/java -cp 
fibo7.jar FiboSample

1836311903

real0m4.847s
user0m4.832s
sys0m0.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  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:

  0x7f97e4b4743f: mov$0x76d08f770,%r8   ;   {oop(a 
'java/lang/invoke/MemberName' = {method} {0x7f97dcff8e40} 'fibo' 
'(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;I)I' in 
'jdk/nashorn/internal/scripts/Script$Recompilation$2$fibo')}
  0x7f97e4b47449: xchg   %ax,%ax
  0x7f97e4b4744b: callq  0x7f97dd0446e0

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


___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Invokedynamic and recursive method call

[Marcus Lagergren]

Remi, I tried to reproduce your problem with jdk9 b44. It runs decently fast. 
When did it start to regress?

Regards
Marcus

> On 30 Dec 2014, at 20:48, Remi Forax  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:
> 
>  0x7f97e4b4743f: mov$0x76d08f770,%r8   ;   {oop(a 
> 'java/lang/invoke/MemberName' = {method} {0x7f97dcff8e40} 'fibo' 
> '(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;I)I' in 
> 'jdk/nashorn/internal/scripts/Script$Recompilation$2$fibo')}
>  0x7f97e4b47449: xchg   %ax,%ax
>  0x7f97e4b4744b: callq  0x7f97dd0446e0
> 
> 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@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

Re: Invokedynamic and recursive method call

[Remi Forax]

ping ?

Rémi

On 12/30/2014 08:48 PM, Remi Forax 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:


  0x7f97e4b4743f: mov$0x76d08f770,%r8   ;   {oop(a 
'java/lang/invoke/MemberName' = {method} {0x7f97dcff8e40} 'fibo' 
'(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;I)I' 
in 'jdk/nashorn/internal/scripts/Script$Recompilation$2$fibo')}

  0x7f97e4b47449: xchg   %ax,%ax
  0x7f97e4b4744b: callq  0x7f97dd0446e0

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

Invokedynamic and recursive method call

[Remi Forax]

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:


  0x7f97e4b4743f: mov$0x76d08f770,%r8   ;   {oop(a 
'java/lang/invoke/MemberName' = {method} {0x7f97dcff8e40} 'fibo' 
'(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;I)I' in 
'jdk/nashorn/internal/scripts/Script$Recompilation$2$fibo')}

  0x7f97e4b47449: xchg   %ax,%ax
  0x7f97e4b4744b: callq  0x7f97dd0446e0

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@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev