State of lambda forms stealing stack frames?

[Jochen Theodorou]

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

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


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