State of lambda forms stealing stack frames?

Jochen Theodorou blackdrag at
Fri Dec 20 13:09:08 PST 2013

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
> 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
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit

More information about the hotspot-dev mailing list