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)

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)

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 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

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

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) 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

Re: The Great Startup Problem

2014-09-01 Thread Charles Oliver Nutter
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

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

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

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