Am 21.12.2013 13:27, schrieb Remi Forax: [...] > the problem is not as awful as you think and moreover part of the > problem is the way you test it. > I'm pretty sure you have call it directly without any warming up, > so your call to fib is first interpreted by the VM, which create a bunch > of stack frames, > when fib is then compiled to assembly code by the JIT, there is still an > awful number of interpreter stack frames on stack which blow the stack > at some point. > So the cause of the stack overflow is not only the way the lambda forms > are initially interpreted but also the fact that in your test you call > fib directly. > > So a way to improve the code is just to do some calls to fib before > calling fib with a big value.
well... I guess I need a different test for this then. In my test I do fib with memoization. Of course if it blows up for fib(45) initially it won't if I first do fib(44) and then fib(45). That is not because the JIT is doing some magic here, it is because then all results till 44 are memoized and I the cached values for the recursive fib(44) and fib(43) values instead of walking down the path again. If I first call fib(44) and then fib(45) without memoization, then it takes much to long to calculate all those BigIntegers. > Now, if you think there is a better way to implement the JSR 292 than > lambda forms, > please share your ideas. Lambda forms are far from perfect but > interpretation of methods with polymorphic signature without growing the > stack is not easy. After the intial invokedynamic was completed I never looked at the details of the implementation from a implementors perspective anymore, only from the pov of a user. I can't say that I would have a better idea. I thought there had been ideas. But I take your comment that my information is wrong, or that they did not work out. > There is something that may work to improve your issue, come to the next > JVM Summit and run in circle, shouting 'tailcall, tailcall', I will join > you :) You mean to say many of the lambda forms are actually tailcalls? bye blackdrag -- 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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
