State of lambda forms stealing stack frames?

[Jochen Theodorou]

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