FORK

[John Rose]

(Moving this conversation from http://mail.openjdk.java.net/pipermail/mlvm-dev/2014-April/005745.html to hotspot-dev.)

On Apr 24, 2014, at 12:44 AM, Charles Oliver Nutter <headius at headius.com> wrote:

> What would it take to make Hotspot forkable? Obviously we'd need to
> pause all VM threads and restarting them on the other side (or perhaps
> a prefork mode that doesn't spin up threads?) but I know there's
> challenges with signal handlers etc.
> 
> I ask for a few reasons...
> 
> * Dalvik has shown what you can do with a "larval" preforking setup.
> This is a big reason why Android apps can run in such a small amount
> of memory and start up so quickly.

They had to do a lot of work to segregate sharable stuff from non-sharable.  I think it would be a useful exercise for us, but it is difficult.  We have pointers everywhere, and every pointer is a chance to break sharing (if it points to something that a process needs to move).

They also have the luxury of running on exactly one Unix OS, whose code they can adjust.  Java runs everywhere, so it cannot easily make deep demands on the OS, like "don't give performance surprises when we fork our VM".

But, two other reasons to work on this problem is data sharing (class and/or application) and AOT compilation; both win bigger to the extent they can can work with untransposed data, directly out of a file (= shared RO memory).

> * Startup time! If we could fork an already-hot JVM, we could hit the
> ground running with *every* command, *and* still have truly separate
> processes.

Yup.  How much does nailgun address this use case, already?  That is, what don't you get today with pre-warmed JVMs?

> * There's a lot of development and scaling patterns that depend on
> forking, and we get constant questions about forking on JRuby.

Over time, we have experimented at length with both forking and single-process multi-tasking (MVM).  Since MVM doesn't make as many demands on the operating system for complex operations, we are more comfortable with that approach.

> * Rubinius -- a Ruby VM with partially-concurrent GC, a
> signal-handling thread, JIT threads, and real parallel Ruby threads --
> supports forking. They bring the threads to a safe point, fork, and
> restart them on the other side. Color me jealous.

Me too.  It's a cute move.  How many OS's does that trick work well on?

> So...given that OpenJDK is rapidly expanding into smaller-profile
> devices and new languages and development patterns, perhaps it's time
> to make it fit into the UNIX philosophy. Where do we start?

In my opinion, with CDS and AOT.

And with squinting suspiciously at our data structures.  (But when I say that it scares folks; who knows where that will end!? :-) )

But a forkable-VM experiment, as a patch within MLVM project, would be a lightweight and easy thing to try.  It might not produce a usable result, but would at least illuminate the problem areas.

— John