create a fork under openjdk

[Christine Flood]

I would be very interested in reproducing a test case where criu startup is
slower than jvm class loading and warm up for anything more than a trivial
application and even then I'd still be curious.  I have not seen that in
any of my experiments.   One optimization that we are working on is having
a full gc and a heap shrinkage to just the working set prior to
checkpointing.  That might help with image size issues.

The security issues as I understand them are:

1) Active secrets, like cached passwords
2) Inactive secrets, like cached passwords which haven't been gc'd yet
3) Address layout consistency

I would argue that programs which are responsible for things like active
secrets should be able to address this issue through save and restore
hooks.

Inactive secrets will be handled by a full gc and heap shrink before the
checkpoint.

This leaves us with restored images having identical heap layouts.  This
can be a great benefit.  I have seen cases where the kernel is smart enough
to share the underlying pages.  However it can be a security risk.  If this
is an important issue we can look at randomizing the java heap upon
restore.  If we did a fullgc and tight compression of the heap before
checkpointing we have all the information we need to do a fast random
permutation on restore.  Please let me know if this is an important issue.


The nuisance issues are:
1) Things like processor count changed so work stealing queues are no
longer working efficiently
2) If you are timing an operation it may look like something that should
take ms is actually taking days because it started before the checkpoint
and finished after the restore.

We are working on restoring the jvm with appropriately sized work stealing
queues.  For GC this should be easy since we forced a full gc before saving
and the queues would be empty.
For everything else it would require copying the work elements into the new
queues and performing some bookkeeping.

I don't have an answer to the timing issue, but I see this as a nuisance
and not a show stopper.


Christine



On Tue, Feb 9, 2021 at 10:56 PM Jiangli Zhou <jianglizhou at google.com> wrote:

> Liam explored using CRIU for taking process snapshots for Javac in the
> past. His finding (based on preliminary measurements) indicated the
> image size could have a heavier impact on startup performance, and
> worse startup time could be observed due to larger images. The
> environment was a cloud build & testing environment.
>
> We want to understand potential security issues associated with taking
> and storing snapshots of live Java processes in production
> environments.
>
> Best,
> Jiangli
>
> On Thu, Feb 4, 2021 at 9:16 AM Christine Flood <chf at redhat.com> wrote:
> >
> > Have you guys looked at CRIU at all?  If you are running on Linux it
> gives
> > you the capability of firing up a warmed up Java application in minutes.
> >
> > For example the TODO app (https://github.com/cescoffier/quarkus-todo-app
> )
> > takes 1.837 seconds to start but only  0.11 seconds to restore.
> >
> > I've attached a console log showing the commands I used.
> >
> > If you want greater control, I've written a Java API you can tinker with:
> > https://github.com/chflood/JavaCriuJar.
> >
> > Unfortunately this is a Linux only capability.
> >
> >
> > Christine
> >
> >
> >
> >
> > On Wed, Jan 27, 2021 at 7:14 AM 李三红(三红) <sanhong.lsh at alibaba-inc.com>
> wrote:
> >
> > > Hello,
> > >
> > > We are working on the fast-startup related development based on
> JDK11u. To
> > > facilitate community collaboration(sharing backports, bug fixing,
> patches,
> > > etc. across different companies/parties based on the repo), we are
> > > exploring
> > > creating the fork of JDK11u under the OpenJDK group [1]
> > >
> > >
> > >
> > > Can anyone help with this, or is there a way/process we can follow to
> do
> > > that? - Your help or any input is much appreciated.
> > >
> > >
> > >
> > > [1]  <https://github.com/openjdk> https://github.com/openjdk
> > >
> > >
> > >
> > > Thanks!
> > >
> > > Sanhong
> > >
> > >
> > >
> > >
>
>