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 that is definitely going to be necessary. Perhaps Attila can comment here. /M On 01 Sep 2014, at 13:03, Vladimir Ivanov <vladimir.x.iva...@oracle.com> wrote: > 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, please, file a bug/let me > know. I'll be happy to fix them. > >> Sergey Kuksenko had a very interesting performance analysis presentation at >> JVMLS this year where ~41% of his runtime for Nashorn with octane.box2d was >> unlined lambda forms. > I already told you in private, but just to let others know. > The reason why there's an uninlined LambdaForm call in Box2D is because > Nashorn does MH caching itself (see [1]). > > HotSpot can't see through the cache and it doesn't do value profiling of > receiver for MethodHandle.invoke*(), so inlining fails. > > Roland experimented with receiver profiling for MethodHandle.invoke* support, > but I'm not aware about any plans to integrate it into the product. > > Best regards, > Vladimir Ivanov > > [1] nashorn.internal.runtime.UserAccessorProperty.userAccessorGetter > nashorn.internal.runtime.UserAccessorProperty.userAccessorSetter > > http://hg.openjdk.java.net/jdk9/jdk9/nashorn/file/adc2b63e654a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/UserAccessorProperty.java#l276 > > And this is basically just the mechanisms pushing parameters and applying > filters around the callsite. Seems like lambdaforms have to be treated > specially (or rather indy callsites) by the JIT. > > >> >> One solution that was proposed for 8u40 was JEP210 (lambda form caching), >> which does indeed keep footprint down, but performance suffers mightily >> since the same lambdaform snippet kan now be used at two completely >> different call sites, which brings us cache pollution. Vladimir is on >> vacation, but even though this brings metaspace down, I don’t think >> performance is back yet. >> >> Even if everything inlinines correctly and deeply (which doesn’t happen all >> he time in C2 for long chains), we still have the problem of holding on to >> this synthetic bytecode/metaspace constructs for the LambdaForms. We really >> don’t want to have all this bookkeeping around something that can be as >> simple as permuting a couple of parameters (yes, it can be more complex, >> same argument applies) >> >> LambdaForms were most likely introduced as a platform independent way of >> implementing methodhandle combinators in 8, because the 7 native >> implementation was not very stable, but it was probably a mistake to add >> them as “real” classes instead of code snippets that can just be spliced in >> around the callsite. (I completely lack history here, so flame me if I am >> wrong) >> >> For both JRuby and Nashorn in the indy world, starting up a process >> generates bytecode where say every 5th to 10th instruction is an indy. >> Lambda code is not that bad, but it can also look pretty hairy. Now, if >> runtime linkage for each of these callsites requires metaspace, hidden >> bytecode generation, anonymous internal classes and the rest of the >> combinatorial explosion Charlie describes, we are setting us up for really >> bad scalability on such an arena. And metaspace of course, goes through the >> roof. Custom runtime linkage is still slow, but at least it only happens >> once.We don’t want to keep adding even more overhead o that. >> >> For 9, it seems that we need a way to implement an indy that doesn’t result >> in class generation and installation of anonymous runtime classes. Note that >> _class installation_ as such is also a large overhead in the JVM - even more >> so when we regenerate more code to get more optimal types. I think we need >> to move from separate classes to inlined code, or something that requires >> minimium bookkeeping. I think this may be subject to profile pollution as >> well, but I haven’t been able to get my head around the ramifications yet. >> >> There are various problems here as well (for example, several of the >> java.lang.invoke combinators create boxing and arrays and do arraycopies), >> stuff that would needed to be optimized away, or it’ll punish any indy call. >> In such an environment we can cheat with annotations like >> @ExplodeThisArrayToLocals or @NoSafePoint or similar magic annotations, >> because after all we own the code we splice in. (Solving local escape >> analysis, which is really the problem in the generic form of callsite IR, >> has so far not been very successful in C2), but even if C2 is a little bit >> legacy, making things like this hard, we might still be able to cheat for >> the limited world/range that is an indy callsite and teach C2 some magic. >> Lots of early performance problems Attila and I had in Nashorn were from >> e.g. MethodHandles.catchExcetption, that had to be rewritten to avoid >> boxing, but I’m talking about a more generic mechanism than this. >> >> Having said this, I don’t think that we can solve the indy scalability >> problems in the current jits, without getting away from the class >> generatation/bytecode spewing that results from an indy callsite being >> compiled. Caching lambda forms brings the memory footprint down, but I am >> already quite worried that it will get nowhere near the performance that is >> needed, due to profile pollution. >> >> If 9 is a platform that supports indy and runs c1 and c2, invokedynamic >> callsites in the JVM, at least in C2, would need some serious love - perhaps >> as described above. >> >> Paul, Vladimir, Rickard - do you have any comments? We had a good discussion >> a couple of weeks ago about profiling callsites in SCA and what to do with >> such callsites. I’d prefer it if one of you guys write down a bit of our >> thoughts from that session, as I am again afraid of making a damn fool of >> myself among genius engineers on this list. Also cc:ing Fredrik. >> >> /M >> >> On 25 Aug 2014, at 10:07, Jochen Theodorou <blackd...@gmx.org> wrote: >> >>> Am 24.08.2014 20:33, schrieb Charles Oliver Nutter: >>>> On Sun, Aug 24, 2014 at 12:55 PM, Jochen Theodorou <blackd...@gmx.org> >>>> wrote: >>>>> afaik you can set how many times a lambda form has to be executed before >>>>> it >>>>> is compiled... what happens if you set that very low... like 1 and disable >>>>> tiered compilation? >>>> >>>> Forcing all handles to compiler early has the same negative >>>> effect...most are only called once, and the overhead of reifying them >>>> outweighs the cost of interpreting them. >>>> >>>> I need to play with it more, though. The property I think you're >>>> referring to did not appear to help us much. >>> >>> I see it as a tradeoff. Yes, one-time-visited callsites may run even slower >>> with this, but I think that is to be measured first. And secondly, you will >>> be up to speed much faster than before, which can maybe outweight the >>> initial cost. I am not saying 1 is an ideal value, but it should be played >>> with. >>> >>>>>> We obviously still love working with OpenJDK, and it remains the best >>>>>> platform for building JRuby (and other languages). However, our >>>>>> failure as a community to address these startup/warmup issues is >>>>>> eventually going to kill us. Startup time remains the #1 complaint >>>>>> about JRuby, and warmup time may be a close second. >>>>> >>>>> how do normal ruby startup times compare to JRuby for a rails app? >>>> >>>> Perhaps 10x faster startup across the board in C Ruby. With tier 1 we >>>> can get it down to 5x or so. It's incredibly frustrating for our >>>> users. >>> >>> I guess for a rails app that is indeed pretty bad. >>> >>>>> All in all, the situation is for the Groovy world quite different I would >>>>> say. >>>> >>>> I'd guess that developers in the Groovy world typically do all their >>>> development in an IDE, which can keep a runtime environment available >>>> all the time. Contrast this to pretty much everyone not from a Java or >>>> C# background, where their IDE is a text editor and a command line. >>> >>> Now I feel almost insulted ;) I get scolded so often, that I treat my IDE >>> only as a better text editor... I agree in general though. >>> I think this is not so much a Groovy thing, as more a java thing though. If >>> you do Grails, you do Spring+Apache most of the time. So you don't start a >>> new server, you deploy to it. And even that may (in development mode) work >>> by just keeping the class files in a certain directory. Unit testing is >>> maybe different. But even there, you don't start a new JVM for each test. >>> Maybe not even for each test suite. Groovy generally goes with the JVM >>> instance here. Actually it is not even easily possible to spawn separate >>> Groovy environments in the same JVM. In Grails a new environment might be >>> spawned on a per suite base. >>> >>> So yes, there are instances kept around, but imho this is already done from >>> the Java world. We do nothing special here most of the time. But of course >>> this is related to slow startup speeds of the JVM. groovy-core has around >>> 7k tests, if for each of them we would have to create a new JVM it would >>> easily take over an hour to execute. With Groovy startup included probably >>> more than 6 hours. >>> >>> Yes, this is a result of the great startup problem. But, the Java community >>> finds ways around. The problem is that in JRuby you have to try to force a >>> Ruby mechanism onto the JVM. And this works properly only if the JVM can >>> behave as much as the Ruby as needed. And in regards to the startup times >>> it does surely not. >>> >>> 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 >> _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
