State of lambda forms stealing stack frames?

Vladimir Ivanov vladimir.x.ivanov at
Thu Jan 9 08:27:56 PST 2014


There's some work going on to reduce heap and stack usage for 
LambdaForm-based JSR292 implementation in 8update. Backporting it to 7u 
will be also considered.

Best regards,
Vladimir Ivanov

On 1/7/14 7:55 PM, Jochen Theodorou wrote:
> Am 06.01.2014 19:48, schrieb Andrew Haley:
> [...]
>> I think that wnat is happening is that you (and Groovy) are
>> unfortunate to be a victim of a design decision that was made a year
>> or so ago.  Back then, invokedynamic was handled by a ton of
>> hard-to-maintain C++ code.  The HotSpot team decide to throw much of
>> it away and generate bytecode instead, in the hope that the optimizer
>> would be able to "see through" all the invocations and smash it all
>> down to a single call in many cases.  Generally speaking, this does
>> work.  However, it can take a while before the optimizer kicks in, and
>> by this time your stack has already overflowed.
> yes, I am aware of the decision... only I was not realizing this problem
> back then.
>> Having said all of that, the lambdas must be fairly amazing to require
>> such a lot of work.  I don't know what fib$_closure1 looks like.
> fib$_closure1.doCall is the the doCall method of the generated
> groovy.lang.Closure which is used for the memoization. As of why it does
> produces such an extremely complex handle is unclear to me too actually.
> I think part of the output is related to fallbacks in case the
> arguments, receiver and such do not fit, also the is a guard with catch,
> that may produce some of it.
> bye Jochen

More information about the lambda-dev mailing list