State of lambda forms stealing stack frames?
vladimir.x.ivanov at oracle.com
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.
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