State of lambda forms stealing stack frames?

[Jochen Theodorou]

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

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