Charles Oliver Nutter | 24 Apr 09:44 2014

FORK

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.
* 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.
* There's a lot of development and scaling patterns that depend on
forking, and we get constant questions about forking on JRuby.
* 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.

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?

- Charlie
Christian Thalinger | 24 Apr 19:42 2014
Picon

Re: FORK


On Apr 23, 2014, at 9:44 PM, Charles Oliver Nutter <headius@...> 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.
> * 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.
> * There's a lot of development and scaling patterns that depend on
> forking, and we get constant questions about forking on JRuby.
> * 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.
> 
> 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?

Good question.  I think you should bring this up on the hotspot-dev mailing list.  People from the runtime
team might have some input to this (at least I hope; because I don’t, really).

(Continue reading)

John Rose | 24 Apr 21:38 2014
Picon

Re: FORK

(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@...> 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
(Continue reading)

Peter B. Kessler | 25 Apr 00:46 2014
Picon

Re: FORK

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@...m> 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).
>
(Continue reading)

John Rose | 25 Apr 02:13 2014
Picon

Re: FORK

On Apr 24, 2014, at 3:46 PM, "Peter B. Kessler"
<Peter.B.Kessler@...> wrote:

>  "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.

...Showing my ignorance of nailgun.  From the descriptions, I assumed it was using that technique.

— John
Charles Oliver Nutter | 25 Apr 04:22 2014

Re: FORK

Thanks for moving the thread John!

On Fri, Apr 25, 2014 at 3:38 AM, John Rose <john.r.rose@...> wrote:
>> * 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).

Perhaps I'll belie my knowledge of kernel-level memory management
here, but I'm confused by this. Wouldn't all such pointers be
indirected through a kernel-level virtual memory table? And wouldn't
any moves be done transparently behind that table? I'm thinking in
terms of vfork here, of course.

I mean...I know Rubinius isn't going back and fixing up pointers after
a fork, and they've got plenty of direct memory references in both C++
and jitted code.

To be clear, I'm also not (initially) interested copy-on-write
capabilities, though there's interesting opportunities there, nor am I
interested in forking as a means to have many small child processes
sharing a large amount of read-only memory. I just want to easily
carry bootstrapped runtime + jitted code to the children.

> 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".
(Continue reading)


Gmane