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 <head...@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 > _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
