Any success on a Mac?

[erizzo-cfa]

My dev machine is an Apple silicon (M3) MacBook, so I'm trying to get this example to work by building a Docker image and running it in Docker Desktop.
Just running the commands in the README without any changes, I can build the initial image:
docker build -f Dockerfile.checkpoint -t example-spring-boot-checkpoint .

But running
docker run -d -v $(pwd)/target/cr:/cr --cap-add=CHECKPOINT_RESTORE --cap-add=SYS_PTRACE -p 8080:8080 --name example-spring-boot-checkpoint example-spring-boot-checkpoint

the container immediately exists with this error in the log:
qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory

At that point I'm over my head. Some googling found a mention of the same error, not in the context of Java or CRaC, that suggested using --platform linux/amd64 in the docker build command. So, grasping at straws, I try with this build command:
docker build -f Dockerfile.checkpoint --platform linux/amd64 -t example-spring-boot-checkpoint .

Run again and now the Spring app starts up. But when I initiate the checkpoint using
docker exec -it example-spring-boot-checkpoint jcmd example-spring-boot JDK.checkpoint
it fails with this error:

2025-09-17T19:46:46.734Z  INFO 130 --- [Attach Listener] jdk.crac                                 : Starting checkpoint
CRIU failed with exit code 1 - check /cr/dump4.log
Command: /usr/share/zulu22.32.17-ca-crac-jdk22.0.2-linux_x64/lib/criu dump -t 130 -D /cr --shell-job -v4 -o dump4.log

The contents of dump4.log is:

(00.000555) Version: 3.17.1-crac (gitid b20-20-g2dc0a51+1)
(00.000936) Running on 5d3b541ec4c0 Linux 6.10.14-linuxkit #1 SMP Wed Sep  3 15:35:15 UTC 2025 x86_64
(00.001062) File /run/criu.kdat does not exist
(00.001422) Pagemap provides flags only
(00.002731) Error (criu/kerndat.c:215): Can't stat self map_files 2: No such file or directory
(00.003134) Error (criu/kerndat.c:1546): kerndat_get_shmemdev failed when initializing kerndat.
(00.003541) Adjust mmap_min_addr 0x8000 -> 0x10000
(00.003618) Found mmap_min_addr 0x10000
(00.003751) files stat: fs/nr_open 1048576
(00.003796) Error (criu/crtools.c:260): Could not initialize kernel features detection.

I'm no Docker or linux expert and this is all over my head. I recognize that this is somehow related to some mismatch or incompatibility between the Zulu JDK and the host OS, but that's all.
Has anyone successfully used this example on a Mac running Docker Desktop?

Thanks in advance.

[erizzo-cfa]

I tried changing the JDK to zulu21.36.19-ca-crac-jdk21.0.4-linux_aarch64 in Dockerfile.checkpoint and rebuild the image (using --no-cache). The resulting container got this error:

Unrecognized VM option 'CPUFeatures=generic'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

That seems strange, since -XX:CPUFeatures=generic JVM option seems to come from Zulu, so not sure why it wouldn't be supported in one of those JVMs.

Anyway, I removed -XX:CPUFeatures=generic from the ENTRYPOINT, re-built and re-ran the image. Initiating the checkpoint seems to work, although I expect some more logging after
2025-09-17T20:09:48.385Z INFO 129 --- [Attach Listener] jdk.crac : Starting checkpoint
Maybe it's just quiet. The JVM (and container) exits after generating the checkpoint files, as expected.

[rvansa]

Hi @erizzo-cfa , I have not tested the example on aarch64, and you have correctly noticed that the example is not arch-agnostic as it should be. I guess that the first error is caused by Docker selecting the aarch64-specific version for Ubuntu (which is a multi-platform image) and downloading the x86_64 JDK (as indicated by the _linux_x64 suffix). So you were right to update the patch for _linux_aarch64.

Yes, CPUFeatures is a JVM option that is implemented on x86_64 only; I think it would be reasonable to support generic and ignore on other platforms as well. CC @jankratochvil

The errors from dump4.log either indicate some permissions issue (you can try to use --privileged instead of --cap-add=..., though it shouldn't be necessary), or kernel compiled without checkpoint/restore features. However you're using rather new kernel and docs say that the /proc/<pid>/map_files should be always present with kernel > 4.3 so I am not sure why would you experience this.

The last behaviour is actually correct: when the checkpoint is created the process is terminated with SIGKILL (exit code should be 137) and so does the container. Have you tried to restore afterwards?

[erizzo-cfa]

Yes, restore works. Sorry I forgot to mention that.
Can you explain the consequences of not using the CPUFeatures=generic option?

[jankratochvil]

Yes, CPUFeatures is a JVM option that is implemented on x86_64 only; I think it would be reasonable to support generic and ignore on other platforms as well. CC @jankratochvil

Yes, aarch64 is planned to be supported (internal tracker ZULU-61036). For other arches they would need to have some CPU features which I am not aware of.

[rvansa]

@erizzo-cfa The option is not present on aarch64 because the problem it is solving is non-existent.

We'll appreciate if you send a PR with changes that would make the example work in your setup, too.

[erizzo]

#17