State of lambda forms stealing stack frames?

[Remi Forax]

On 12/20/2013 10:09 PM, Jochen Theodorou wrote:
> I know on the jvm languages summit this year many already complained 
> about this problem. It is not new (this and the additional memory 
> consumption). I know there have been plans to make lambda forms more 
> "lean". What I don't know is the progress in that. But from the 
> reactions so far I take it that there will be no improvement before 
> the final release candidate. Taking vocation around this time into 
> account there is less than 30 days left

Hi Jochen,
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.

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.

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

cheers,
Rémi,


>
> Am 19.12.2013 15:43, schrieb Vicente-Arturo Romero-Zaldivar:
>> Hi Jochen,
>>
>> Interesting issue but I think the list for this is
>> hotspot-dev at openjdk.java.net.
>>
>> Thanks,
>>
>> Vicente
>>
>>
>>
>> On 19/12/13 13:57, Jochen Theodorou wrote:
>>> Hi all,
>>>
>>> I originally did sent this to another list, so sorry if someone sees
>>> this again... but since I got no reaction at all...
>>>
>>> I wanted to ask what the currrent state of invokedynamic using
>>> additional stack frames through lambda forms is. Will there be a
>>> jdk1.8.0 without the consumption of stack frames or not? Will there be
>>> any at all? Will there be a fix for jdk7?
>>>
>>> I am seriously afraid of larger systems making use of invokedynamic a
>>> lot. To illustrate the gravity of the problem look at this:
>>>
>>> @groovy.transform.Memoized
>>> BigInteger fib(BigInteger x) {
>>>       x<2?x:fib(x-1)+fib(x-2)
>>> }
>>>
>>> this code will produce some background code resposible for caching
>>> results and as such increasing the maximum x. The current 
>>> implementation
>>> could be much better but I show this to compare our old way in Groovy
>>> using custom callsite caching with method generation at runtime to
>>> invokedynamic. So in the old version I can go up to fib(292) and won't
>>> stack overflow. With jdk7u25 and indy this is similiar, even though
>>> slightly less. But with later versions of jdk7 and jdk8 the maximum of
>>> the indy version is fib(45)... 5-6 times less. Since the results are
>>> cached it is really only like going down one side of a tree of
>>> calculations here, meaning if I need the double amount of stack frames,
>>> it will half x.
>>>
>>> Are there any real plans to improve the situation?
>>>
>>> bye Jochen
>>>
>>
>
>