Re: The Great Startup Problem

2014-09-01 Thread 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.La

Re: The Great Startup Problem

2014-09-01 Thread Jochen Theodorou
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.interpretN

Re: [9] RFR (S): 8056926: Improve caching of GuardWithTest combinator

2014-09-01 Thread Paul Sandoz
On Aug 29, 2014, at 7:20 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8056926/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8056926 > > Cache GuardWithTest per erased to basic types signature. > > GWT shape is made friendly to sharing: > * GWT MH is implemented a

Re: [9] RFR (S): 8056926: Improve caching of GuardWithTest combinator

2014-09-01 Thread Vladimir Ivanov
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 InvokerBytecodeGenerator.emitSelectAlternative). Best regards, Vladimir Ivanov On 9/1/14, 1:48 PM, Paul

Re: The Great Startup Problem

2014-09-01 Thread Vladimir Ivanov
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

Re: [9] RFR (S): 8056926: Improve caching of GuardWithTest combinator

2014-09-01 Thread Paul Sandoz
On Sep 1, 2014, at 12:29 PM, Vladimir Ivanov 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 > InvokerBytecodeGenerator.emitSelectAlte

Re: The Great Startup Problem

2014-09-01 Thread Vladimir Ivanov
Marcus, And lambdaform code that never really has a chance to be properly optimized - sometimes just simply because the JIT stops inlining, or sometimes because java.lang.invoke is full of boxing and arraycopies that simple don’t go away. If you have any info about any of those problems, pleas

Re: [9] RFR (S): 8056926: Improve caching of GuardWithTest combinator

2014-09-01 Thread Vladimir Ivanov
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 wrote:

Re: The Great Startup Problem

2014-09-01 Thread Vladimir Ivanov
Jochen, 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. "N frames per chain of N method handles" looks reasonable for me, but it depends on average number of transformations users a

Class hierarchy analysis and CallSites

2014-09-01 Thread MacGregor, Duncan (GE Energy Management)
I really should be posting some stuff to the startup thread, but I need some time to read over it (especially John’s post) carefully first. However since this list is being active again… I had a cunning idea that we had almost enough information present on our method objects to do proper class

Re: Class hierarchy analysis and CallSites

2014-09-01 Thread Charles Oliver Nutter
On Mon, Sep 1, 2014 at 8:46 AM, MacGregor, Duncan (GE Energy Management) 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 checks that require g

Re: The Great Startup Problem

2014-09-01 Thread Charles Oliver Nutter
On Mon, Sep 1, 2014 at 2:07 AM, Vladimir Ivanov 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 the problem for you? Thi

Re: The Great Startup Problem

2014-09-01 Thread Jochen Theodorou
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 depe

Re: The Great Startup Problem

2014-09-01 Thread Marcus Lagergren
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

Re: Class hierarchy analysis and CallSites

2014-09-01 Thread Mark Roos
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 call

Re: Truffle and mlvm

2014-09-01 Thread Mark Roos
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 http://mail.op