[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-lambda-dev
Subject:    Re: State of lambda forms stealing stack frames?
From:       Vladimir Ivanov <vladimir.x.ivanov () oracle ! com>
Date:       2014-01-09 16:27:56
Message-ID: 52CECE0C.8060905 () oracle ! com
[Download RAW message or body]

Jochen,

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
>

[prev in list] [next in list] [prev in thread] [next in thread]