State of lambda forms stealing stack frames?

Remi Forax forax at univ-mlv.fr
Sun Dec 22 10:59:07 PST 2013


On 12/21/2013 04:17 PM, Jochen Theodorou wrote:
> 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.

You can call fib with small values, the idea is to be sure that when you 
call fib(100),
fib has already been compiled in assembly code.


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

Some lambda forms are tailcalls but there is something more important,
when a lambda form does a direct call at the end to a Java method,
it is usually possible to compact the stack frame at that time.

>
> bye blackdrag
>

cheers,
Rémi



More information about the mlvm-dev mailing list