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 > _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
