Add a JDK with CRaC

[obourgain]

I would like to try something with CRaC. I don't think SDKMan can install it, could you do it manually?
Could you install it?
It is available from Azul, but is a specific version of Zulu.
https://www.azul.com/downloads/?version=java-21-lts&os=fedora&architecture=x86-64-bit&package=jdk-crac#zulu

Thank you.

[lost22git]

Is CRAC only optimized the startup time

[obourgain]

CRaC snapshots the state of the process and reloads it. This includes code compiled by the JIT, and could reduce time to peak performance.

[gunnarmorling]

Yeah, I think we can add that. Struggling with some more general issues with the environment right now tough, so it may take a bit.

[obourgain]

That's not urgent, I did some tests and using it in a restricted environment would probably take a lot of your time to configure everything correctly, and you already gave a lot of time.

[jerrinot]

Sdkman has Liberica and Zulu builds with CRaC.

There are complications tho:

1. CRaC relies on (a fork of) Criu which requires broad permissions. So after installing CRaC-aware OpenJDK build you have to change criu ownership to root and setuid. It's a complication, but nothing too bad.
2. My understanding is that the way to use CRaC is that there are jdk.crac packages inside JDK, but applications are not supposed to use it directly. They should use a 3rd party library in the org.crac namespace, which internally delegates to jdk.crac (when available, otherwise noop). So this would break the no-dependency policy of the challenge. But perhaps for the sake of experiment, you could do the same thing the library does, I don't think there is anything special about the library.

FWIW: I tried a quick experiment:

[...]
static boolean execute = true;
static boolean restored = false;
[...]

static class Hook implements Resource {
        @Override
        public void beforeCheckpoint(Context<? extends Resource> context) {
            System.out.println("Before checkpoint");
            execute = false;
        }

        @Override
        public void afterRestore(Context<? extends Resource> context) {
            System.out.println("After restore");
            execute = true;
            restored = true;
        }
    }

    public static void main(String[] args) throws Exception {
        Core.getGlobalContext().register(new Hook());
        while (execute) {
            long msStart = System.currentTimeMillis();
            calculate();
            long durationMs = System.currentTimeMillis() - msStart;
            System.out.println("Pure calculation took " + durationMs + " ms");

            execute = false;
            if (!restored) {
                Core.checkpointRestore();
            }
        }
    }

Interestingly enough, after restoring from a snapshot the aggregation took longer (by a lot, 1s or so) than the first execution.
I thought that perhaps the restore itself was too slow, but it looks it's the calculation. My guess it that the 2nd iteration (=the 1st after restore) triggers deoptimizations. But I have yet to validate this, maybe in the evening.

[gunnarmorling]

Nice. Thx for sharing, @jerrinot! Would be curious to know how an entry would fare with CRaC.