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

[Charles Oliver Nutter]

Just to make it clear here, I'm editing the subject...my interest is
in "process forking", not "open source forking" :)

- Charlie

On Tue, Nov 29, 2011 at 2:12 AM, Charles Oliver Nutter
<headius at headius.com> wrote:
> Ok, hypothetical situation. What if a patch were crafted for OpenJDK
> that could make it possible to safely fork(2) the JVM process. What
> would it look like?
>
> Obviously VM-critical threads would have to be restarted. Such a thing
> is certainly possible; the Rubinius VM maintains background threads
> for JIT requests, etc, and before forking forces them to a safe point.
> After forking, they are resumed at with their original state. Could
> this be done for the OpenJDK worker threads?
>
> On a JVM I have just started, running jruby -e "sleep", I see the
> following non-userland threads:
>
> * DispatchQueue_1: com.apple.main-thread  (serial)
>
> This is presumably the thread started up to handle Cocoa events. I
> assume there would be a way to re-start it on the other side.
>
> * The main thread
>
> This is the actual JVM "main" thread, and on my trace the stack tops
> out in the "sleep" monitor. We can assume this is the thread we want
> to survive forking.
>
> * Eight GC threads
>
> Possible to force them to a safe point and re-launch on the other
> side? The stacks they're sitting on are not very deep...
>
> * An unidentifier thread
>
> It looks like this...I'm not sure what this one is doing:
>
>          2597 java_start(Thread*)
>            2597 VMThread::run()
>              2597 VMThread::loop()
>                2597 Monitor::wait(bool, long, bool)
>                  2597 Monitor::IWait(Thread*, long long)
>                    2597 os::PlatformEvent::park(long long)
>                      2597 _pthread_cond_wait
>                        2597 __semwait_signal
>
> * Java: Reference Handler
>
> The java.lang.ref handler. Presumably this could also be restarted,
> since normally it sits there doing nothing...just waiting for work.
>
> * Java: Finalizer
>
> Again, a thread that normally does no work and could presumably be restarted.
>
> * Java: Signal Dispatcher
>
> This is certainly trickier, but I assume the same signal handling
> logic that works in the parent could be restarted in the child without
> a great deal of effort.
>
> * Two Java: C2 CompilerThread0
>
> Normally not doing anything; presumably could be restarted.
>
> * Java: Service Thread
> * Another unknown thread
>
> These looks similar to the unknown thread above. I am guessing these
> threads are more OS X-specific stuff...
>
> ...
>
> So, most of the threads in question seem like they could be paused,
> saved off in some way, and restarted on the other side. Of course it's
> not that simple...I assume there's on-stack state that would need to
> be translated and bootstrapped in the child. I also assume the JVM has
> some intimate knowledge of memory layout that might go all wacky in
> the presence of fork. But is something like this feasible in theory?
>
> I ask because one of the biggest complaints from JRuby users is the
> inability to fork...not just for doing fork+exec-style process
> launching, but for initializing some state and preforking children.
>
> And JRuby's not alone. Dalvik supports forking, which is a large part
> of why it's able to boot small Java applications so darn quickly; the
> base Dalvik process has already initialized a bunch of VM and Android
> state, and the foked child just boots application-specific logic.
>
> I'm interested in finding a way to make this happen.
>
> - Charlie
>