The Great Startup Problem
blackdrag at gmx.org
Sun Aug 24 17:55:28 UTC 2014
Am 22.08.2014 22:08, schrieb Charles Oliver Nutter:
> 2. Lambda forms are too slow to execute and take too long to optimize
> down to native code. Lambda forms work sorta like the tiered compiler.
> They'll be interpreted for a while, then they'll become JVM bytecode
> for a while, which interprets for a while, then the tiered compiler's
> first phase will pick it up.... There's no way to "commit" a lambda
> form you know you're going to be hitting hard, so it takes FOREVER to
> get from a newly-bootstrapped call site to the 5 assembly instructions
> that *actually* need to run.
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?
> 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?
> What are the rest of you doing to deal with these issues?
It depends on the usage I guess.
For command line utilities even the startup time of a pure JVM used to
be too slow. For that kind of work something like Drip can help, since
it is only a small VM that is needed. And there is no need to have it
going to some kind of optimized state first. The next bigger application
with some kind of approach like that is Grails, and it seems to work for
them, though they don't use drip, afaik they use a client-server system
Most comparable to Rails in the Groovy world would be Grails I guess.
But there is a huge amount of Java involved, so that there is maybe no
compare. Also the style of applications is different.... Ruby used not
really to know about multithreading so it was normal to just fork and
things like that. And ultimatively, we have no Rails to compete with in
All in all, the situation is for the Groovy world quite different I
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org
More information about the mlvm-dev