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)
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)
I'd like to focus on reducing amount of LambdaForm instances.
It benefits both dynamic memory footprint (less LambdaForms = less
heap/metaspace used) and warmup (less LambdaForms = less LF
instantiation/interpretation/bytecode translation).
After JVMLS we had a discussion on that topic and
On Sep 1, 2014, at 12:29 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Thanks, Paul.
There's no need to add @ForceInline on selectAlternative.
It is used only during LF interpretation. There's an intrinsic for GWT
combinator, which encodes it as a branch (see
FTR, selectAlternative intrinsic is there from the very beginning.
Recent changes improved how intrinsics are represented on LF level +
added a bunch of new intrinsics.
Best regards,
Vladimir Ivanov
On 9/1/14, 2:49 PM, Paul Sandoz wrote:
On Sep 1, 2014, at 12:29 PM, Vladimir Ivanov
On Mon, Sep 1, 2014 at 8:46 AM, MacGregor, Duncan (GE Energy
Management) duncan.macgre...@ge.com wrote:
Has anybody else tried doing this sort of thing as part of their
invokeDynamic Implementation? I’m curious if anybody has data comparing the
speed of GWT class comparison based PICs with
On Mon, Sep 1, 2014 at 2:07 AM, Vladimir Ivanov
vladimir.x.iva...@oracle.com wrote:
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
Am 01.09.2014 15:24, schrieb Vladimir Ivanov:
[...]
N frames per chain of N method handles looks reasonable for me, but it
depends on average number of transformations users apply. If the case of
deep method handle chains is common in practice, we need to optimize for
it as well and linear
Ah yes- this was a bad example given that we cache the lambda forms. Sorry. I
do see lambda form execution time for other things that aren’t inlined, though.
Let me get back to you with profiles.
When it comes to generating call site specific typed invokers as discussed in
this thread, I think
Duncan
I have looked on and off at using the class hierarchy for method lookup.
What drives that
is noticing that most methods only have one implementation and so my PICs
can get
overloaded with receivers which all dispatch to the same method. This is
one on my
main sources of megamorphic
Thomas, Thanks I did read Chris' note and it sounds promising.
Is there some reading on this?
regards
mark
p.s. I am still wondering why Ruby was the target, not why there was
a target.___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
11 matches
Mail list logo