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
