Re: Invokedynamic and recursive method call

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:

Re: Invokedynamic and recursive method call

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: Bu

Re: Invokedynamic and recursive method call

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 t

Re: Invokedynamic and recursive method call

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

Re: Invokedynamic and recursive method call

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 consta

Re: Invokedynamic and recursive method call

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 heav

Re: Invokedynamic and recursive method call

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

Re: Invokedynamic and recursive method call

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

Re: Invokedynamic and recursive method call

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 i

Re: Invokedynamic and recursive method call

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 inli

Re: Invokedynamic and recursive method call

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,

Invokedynamic and recursive method call

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 M