Am 01.09.2014 09:07, schrieb Vladimir Ivanov:
Jochen,
The stack traces you provide are so long due to LambdaForm
interpretation. Most of the stack frames are the following:
java.lang.invoke.LambdaForm$NamedFunction.invokeWithArguments(LambdaForm.java:1147)
java.lang.invoke.LambdaForm.interpretName(LambdaForm.java:625)
java.lang.invoke.LambdaForm.interpretWithArguments(LambdaForm.java:604)
java.lang.invoke.LambdaForm$LFI.479397964.interpret_L(LambdaForm$LFI:-1)
We are aware about it and plan to improve the situation in 8u40.
The idea is to precompile (to bytecode) the every element of method
handle chain when indy call site is bound. It allows to skip LF
interpretation and hence reduce worst case stack usage.
Stack usage won't be constant though. Each compiled LF being executed
consumes 1 stack frame, so for a method handle chain of N elements, it's
invocation consumes ~N stack frames.
Is it acceptable and solves the problem for you?
Let me ask you what you consider as acceptable. I am quite interested in
the JVM-engineers point of view here.
As for Groovy... the 55 frames are the case of a one argument method
call and cached. The lines you mention appear there 9 times, so I would
safe 27 frames, leaving 28. That's half of what it was before and as
such better for sure, but 28 is still a lot I would think. But I think
you did not mean that. You did mean every handle involved becomes one
frame. So how many frames will it be in this simple case:
I have a no-arg method call, I have to do a guard to see if the receiver
runtime class stays the same. I my reading that makes, 1 for dropping
stuff from the callsite, since the callsite has more arguments than the
method (meta information). Then 1 for the guard, even if the guard is
true. One for the type transformation of the guard, since we work with
exact types and the callsite as well as the target method do have types.
Then the handle for the target method itself, together with another type
transformation.
That makes 5 frames in between. 5 is worlds better than 53.
We discussed an idea to generate custom bytecodes (single method) for
the whole method handle chain (and have only 1 extra stack frame per MH
invocation), but it defeats memory footprint reduction we are trying to
archieve with LambdaForm sharing.
I wonder if that is the case for Groovy as well. Our old callsite
mechanism does have only 1 frame (upon second execution). Because by
then we generated a class for the callsite that does all the argument
transformation, checks and target method execution. So compared to that
I would not expect a memory increase.
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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
