Towards save-world for ABCL

[Alan Ruttenberg]

A limiting factor in uptake and wider-scale use of ABCL, and java
applications in general, has been startup time. Some native lisps have a
save-world or save-image facility
<https://stackoverflow.com/questions/39133421/how-to-properly-save-common-lisp-image-using-sbcl#39148561>
that
lets you create a snapshot of a running lisp which can then quickly
resumed. I've long wanted something like this for ABCL - loading the system
I work on (LSW <https://github.com/alanruttenberg/lsw2>) takes maybe 15
seconds on my reasonably fast laptop. This makes it annoying to run for
short tasks, or to run in a pipe with non-lisp tooks. I also work with OWL
ontologies that can take 10s of minutes to classify. I'd very much like to
save that work so that I can fire off quick query, or reduce development
time turnaround.

Recently I've started to play with docker
<https://www.docker.com/community-edition> and found that there is starting
to be support for CRIU <https://github.com/xemul/criu>, which allows one to
save the state of linux processes/containers and then restart them. I've
just run a first successful test of this and I wanted to share the recipe,
see if others have poked at this, see if there is interest in thinking
about / implementing more transparent support for this for ABCL, and in
case it is useful, as is, for someone.

1. You may need to install support for CRIU into docker. I had to do this
with docker for mac <https://www.docker.com/docker-mac>, which is what I'm
running. I think it's built into docker for linux, and am not sure about
docker for windows. To install the mac support I followed instructions at
https://hub.docker.com/r/boucher/criu-for-mac/

run: *docker run --rm -it --privileged --pid=host boucher/criu-for-mac*

2. Start a container that loads up ABCL and give it enough time to load
(about 20 seconds in my case)

*docker run -id lsw2/devel /home/lsw/repos/lsw2/bin/lsw*

Note that the shell prompt returns immediately. There's no automatic way,
at the moment, to see when the lisp has finished loading.

In this case lsw2/lisp is my image built according to instructions at
https://github.com/alanruttenberg/lsw2/tree/owlapiv4/virtual-machine

/home/lsw/repos/lsw2/bin/lsw is the command that runs ABCL and loads my
system inside the container.

Replace these with your own, or use Mark Evenson's easye/abcl as an image
to try (or use his Dockerfile
<https://github.com/armedbear/abcl/blob/master/Dockerfile> as a base) .
That image starts ABCL by itself, so you don't need to do it on the docker
run command line as I do above.

The -i switch hooks up stdin and the -d switch lets the container sit
running in the background. Once ABCL is finished starting, the process in
the container is effectively sitting at the repl prompt, waiting for input,
but its stdin isn't connected to anything at the moment.
Note that if you use the -t switch, as one commonly sees in docker
examples, the checkpoint stage below will fail.

3. run: *docker ps* to get the Container ID for the container just created.

4. run: *docker checkpoint create <container-id> <checkpoint-name>*
<container-id> is the id you just got from docker ps.
<checkpoint-name> is a label you choose for the saved-state.

On completion of the command the container stops running.

5. run: *docker start --checkpoint <checkpoint-name> <container-id>*

After a much quicker startup(fraction of a second),  the container is
running again. You can interact with it by

6. run: *docker attach <container-id>*

Hit return and you'll get the REPL prompt and can type something in to
eval. Use control-d (EOF) to detach. You can reattach the same way again.
Type (quit) to the repl, or run *docker kill <container-id>* to stop the
container for good and exit.

--

Obviously there is MUCH more that needs to be done to make this easy and
practical, e.g.

- packaging: While one can package up an image that a container can start
from and easily serve it, the checkpoints are not easily attachable to
images. Rather, they are specific to containers, and saving process state
isn't couple with saving file-system state. That could be managed with some
wrapper scripts that checkpoints on first run, etc. I'm also not sure of
the mechanics of running several containers from the same checkpoint, at
the same time. I'm guessing that sort of thing will be more directly
supported in docker within a year or 2, if not sooner.

- Doing this without docker: While using docker means that you can create
an artifact that runs in all platforms, it may be easier to package up an
application that will certainly run under linux to use CRIU directly. It
may even be more practical to use CRIU inside the container instead of
docker checkpoint. dunno.

- reliability: I haven't run many tests yet to try to ensure that the
checkpointed process doesn't have any problems - I've just tried simple
things at the prompt. I haven't experimented with, e.g. running a web
server inside ABCL and seeing if there are any issues with ports or network
processes on restart.

- restart hooks: some things may not be able to be saved. We'll need a
provision for hooks that run when restarting and documentation about when
they have to be used.

Alan Ruttenberg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20170914/1f4ae120/attachment.html>