Hi Alan,
Alan Ruttenberg alanruttenberg@gmail.com writes:
Thanks for starting this. It would be a great contribution.
Something I've wanted for a very long time is to have a checkpoint/resume for ABCL - would function like save-world in other lisps. Doing this would make it practical to build tools which use lots of code, such as my own, start up quickly and become practical for script usage. Docker allegedly has some support for this but I've never seen it work on MacOS. If this is something you have any awareness of how to do I'd love to see that integrated into an ABCL docker image.
I've never been able to get Docker checkpoint/restore to work for me. I tried a while ago (IIRC, prompted by you asking a similar question on slime-docker!) and ran into https://github.com/moby/moby/issues/35691 and I just tried again and am currently seeing https://github.com/moby/moby/issues/41639. Unfortunately I don't have the time to experiment with various Docker and CRIU version combos to find one where they actually work together.
However, from what knowledge I have been able to gather, it appears that nothing special needs to be added to the image to make C/R work. It happens entirely outside the view of the running processes and is supposed to just enable the process to pick up exactly where the checkpoint happened, none the wiser that it got paused.
Could you say a few words about the image OS environment and your considerations when choosing it, and a bit on how to understand the tags?
Sure! All official images must inherit from other official images and if an official image exists for a needed software stack you're highly encouraged to use it instead of installing the software yourself (to help encourage layer reuse). I'm aware of at least three Java runtime images: openjdk, adoptopenjdk, and amazoncorretto. My decision to use openjdk as the base image was semi-arbitrary in that I've used openjdk before, the in-tree Dockerfile for building ABCL from source uses openjdk, and for other official images that support only one Java runtime, openjdk seemed to be the most used. However, there certainly is precedent for Java based images to support multiple runtimes via tags so if ABCL users think that's important or if the default should be changed, that's definitely something we can do.
For the Windows images, we're limited to what the Official Images team's hardware is. They're running a version of Windows Server that supports 1809 at most, so that's why the Windows versions appear to be so old.
For Linux images, the openjdk image is built for both Debian Buster and Oracle Linux 8. Buster is their default for Java versions < 15 and Oracle Linux is their default for >= 15. I chose to make the ABCL images default to Buster for all Java versions beacuse, personally, it seemed a little ridiculous to change OSes that drastically based only on Java version. I didn't create any Oracle Linux variants of the ABCL image because Buster is almost certainly the most widespread base image and I took a guess that ABCL users would prefer that. But if there's a desire for Oracle Linux based images, they would be easy to add.
The openjdk image also builds for Alpine, but only on the cutting edge versions of Java and they drop support for it as soon the Java version reaches General Availability.
Last, the openjdk image does have tags for either a JRE or JDK install of Java. I chose to use only the JDK since that's the most useful, but if there is desire for images that have only the JRE, that is also possible.
With that out of the way, onto the tags for ABCL! Every tuple in my original email has a canonical tag of the form $ABCL_VERSION-$JAVA_VERSION-$OS (note processor architecture is omitted). For instance: 1.8.0-jdk15-buster. Then, each of these canonical tags have aliases. These aliases either omit a segment of the tag (if it is the latest version of that particular element) or provide an alternate form.
For instance, 1.8.0-jdk15-buster, 1.8-jdk15-buster, and jdk15-buster are all the same image. 1.8 is an alias for the latest release in the 1.8 series and because 1.8.0 is also the latest ABCL release, it's the default ABCL version and is omitted. jdk in the java segment of the tag is an alias for the latest supported JDK (currently 15). Last, there is a latest tag that is an alias for the latest of everything (ABCL 1.8.0, JDK 15, and Buster on Linux or if on Windows, the latest version of Windows your OS supports).
The architecture is handled by pushing the images to separate organizations on Docker Hub (such as arm64v8/ or amd64/ for the Official Images program) and then tied together in the primary organization using manifest lists. This results in Docker pulling the correct version of the image based on your hardware (or what you request using the --platform CLI flag).
Hopefully that helps!
-Eric