Process-level fork on OpenJDK...is it madness?

Charles Oliver Nutter headius at headius.com
Tue Nov 29 14:54:18 PST 2011


On Tue, Nov 29, 2011 at 4:34 PM, Thomas Wuerthinger
<thomas.wuerthinger at oracle.com> wrote:
> What kind of initialization work is this? Could the result of that work
> be cached?

I can describe the work done in JRuby's boot.

We have managed to get JRuby's basic runtime to start up pretty fast;
about 0.3 to 0.5s on my high-end MBP. However on other systems,
especially on 64-bit Linux, startup time is still quite a bit slower.
The Apple JDK does an amazing job of speeding startup that no other
builds seem to have matched yet.

JRuby's base init involves:

* Constructing metaclasses for all the core Ruby classes like String,
Array, etc. It's difficult or impossible to cache this because they
are essentially key/value tables of pointers to methods...in our case,
thousands of tiny classes that subclass DynamicMethod.
* Initializing native bindings for POSIX features. Loading the libffi
binding dynamically and programmatically wiring up all the functions
we use takes a bit of startup time.
* Loading additional .rb sources from classloader resources. Parts of
JRuby (more and more) are implemented in Ruby; as a result, we have to
load a bunch of Ruby code on boot.

The bigger part of startup is loading all the third-party libraries
that a user might need in their app. Those sources need to be parsed
every time, turned into an AST, and partially executed to boot. All
the code that does parsing and interpretation is cold initially, and
so we have slow startup no matter what we do.

We have experimented with serializing the parse tree or precompiling
to bytecode, but neither case was actually faster than our parser.

If the JVM had the ability to fork, users could potentially boot a
baseline application image and then fork instances from that to run
iterative tests, etc, rather than having to re-boot the entire runtime
and application's dependencies every time.

I'm also looking into the possibility of doing this on Dalvik; we
could keep a running JRuby image in memory and then fork off that for
JRuby-based applications, reducing startup time significantly.

- Charlie


More information about the mlvm-dev mailing list