State of lambda forms stealing stack frames?

Jochen Theodorou blackdrag at gmx.org
Sat Dec 21 07:17:46 PST 2013


Am 21.12.2013 13:27, schrieb Remi Forax:
[...]
> the problem is not as awful as you think and moreover part of the
> problem is the way you test it.
> I'm pretty sure you have call it directly without any warming up,
> so your call to fib is first interpreted by the VM, which create a bunch
> of stack frames,
> when fib is then compiled to assembly code by the JIT, there is still an
> awful number of interpreter stack frames on stack which blow the stack
> at some point.
> So the cause of the stack overflow is not only the way the lambda forms
> are initially interpreted but also the fact that in your test you call
> fib directly.
>
> So a way to improve the code is just to do some calls to fib before
> calling fib with a big value.

well... I guess I need a different test for this then. In my test I do 
fib with memoization. Of course if it blows up for fib(45) initially it 
won't if I first do fib(44) and then fib(45). That is not because the 
JIT is doing some magic here, it is because then all results till 44 are 
memoized and I the cached values for the recursive fib(44) and fib(43) 
values instead of walking down the path again.

If I first call fib(44) and then fib(45) without memoization, then it 
takes much to long to calculate all those BigIntegers.

> Now, if you think there is a better way to implement the JSR 292 than
> lambda forms,
> please share your ideas. Lambda forms are far from perfect but
> interpretation of methods with polymorphic signature without growing the
> stack is not easy.

After the intial invokedynamic was completed I never looked at the 
details of the implementation from a implementors perspective anymore, 
only from the pov of a user. I can't say that I would have a better 
idea. I thought there had been ideas. But I take your comment that my 
information is wrong, or that they did not work out.

> There is something that may work to improve your issue, come to the next
> JVM Summit and run in circle, shouting 'tailcall, tailcall', I will join
> you :)

You mean to say many of the lambda forms are actually tailcalls?

bye blackdrag

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