State of lambda forms stealing stack frames?

[Jochen Theodorou]

Hi all,

I wanted to ask what the currrent state of invokedynamic using 
additional stack frames through lambda forms is. Will there be a jdk8 
first release 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 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 metho generation at runtime and all 
that, 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 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