Peter B. Kessler
Peter.B.Kessler at Oracle.COM
Thu Apr 24 22:46:57 UTC 2014
On 04/24/14 12:38, John Rose wrote:
> (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
> Yup. How much does nailgun address this use case, already? That is, what don't you get today with pre-warmed JVMs?
What I remember about nailgun is that everything runs in the same server process, separated only by classloaders. That's obviously good enough for some applications. But it has a lot of security issues (the nailgun web page points that out). It also doesn't protect you from memory pigs running in the same VM causing a lot of GC activity, etc. And if the VM crashes it takes down everything running in that process. "Truly separate processes" as Charlie asks for would solve many of those problems. Maybe by "pre-warmed JVM's" you mean a service that starts (and warms up) a JVM for you to run on when you eventually type a "java" command. That would just (?) take cycles and memory.
>> * 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
More information about the hotspot-dev