State of lambda forms stealing stack frames?

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