JRuby startup costs [was: Process-level fork on OpenJDK...is it madness?]

[Charles Oliver Nutter]

On Wed, Nov 30, 2011 at 3:36 AM, Marrows, George A (GE Energy) > Are
you saying that
>  ruby source on disk -> parse tree in memory -> bytecode in JVM
> takes the same amount of time as
>  bytecode on disk -> bytecode in JVM
> ? If so, how do you think that is?

Actually, since JRuby has an interpreter, the comparison is:

a) ruby source to AST, start interpreting

versus

b) bytecode on disk to bytecode in memory, JVM interprets

The problem we've seen in (b) is that while bytecode can load quickly,
bytecode *verification* is considerably more costly than our parser.
We can get the AST up and running more quickly than the JVM can load
and verify bytecode.

Another more subtle aspect is that our interpreter gets "hot" *very*
quickly, since it's running the same code over and over again
regardless of what Ruby code is executing. If all that Ruby code were
JVM bytecode, each piece would have to get "hot" to run fast...so
interpreting wins there too.

> Or just that any difference is lost as noise in the bigger start-up
> cost?

Over the longer-term startup, things get a little muddy. We know that
JVM warmup is a factor, but even if we run multiple app startups in
the same process (using something like Nailgun) we still don't boot as
fast as we'd like. So there's probably more we can fix in the load
process for large apps, as well as exploring things like preforking.

- Charlie