All MethodType objects are interned on the Java side and since the current portable mode implementation allows classes used early during the VM initialization to be pre-initialized accepting their new state instead of restoring the checkpointed one, the MethodType cache sometimes gets re-created which means that the restoration mechanism has to add each restored MethodType object into the cache. This is done by invoking Java to create such objects — execution of the Java code may trigger initialization of classes being restored which is forbidden (as they may be not yet be fully restored thus being unusable) and currently results in a deadlock on the restoring (i.e. main) thread.

When the deadlock happens it is accompanied by a warning in the form Linking/initializing thread 'main' is waiting for SomeClass to be restored — this means the checkpoint is unusable and the VM has to be killed. Re-creating the checkpoint usually solves the problem.

This is currently left as is since this situation is not easy to circumvent in the current implementation (it would require checking initialization status of all of the classes involved in MethodType creation and caching) and the issue will be resolved when restoration of all classes is implemented.

Below are lists of tests that cause some kind of problems. The cases are marked as resolved when they either get fixed or it is expected for the test to fail in on current development stage and it has been temporarily marked as ignored.

Tests that fail steadily because of the introduced changes:

• jdk/jshell/ExceptionsTest
  • Started failing after 15978bc added unconditional portable CRaC support into jdk.internal.jimage classes via proxies
  • Traditional CRaC did that the same way but it was conditional: a proxy was only generated on 32-bit platforms — in the test suite only jdk/jshell/ExceptionsTest is run on such platform (linux-x86) and it also fails steadily in openjdk/crac codebase
  • Fixed in c58967c by updating the package of the proxy class used by the test
• runtime/cds/NonBootLoaderClasses, runtime/cds/serviceability/ReplaceCriticalClassesForSubgraphs
  • Also started failing after 15978bc added unconditional portable CRaC support into jdk.internal.jimage classes via proxies
  • I don't know what exactly makes the CDS test fail (the existence of proxy classes influences CDS's class lists?), a consultation with someone more experienced with proxies' internals is needed to fix the tests both for portable and traditional CRaC implementations since they both use proxies and break these tests
  • Marked as problematic in bb2007c

Tests that fail but seemingly unrelated to the introduced changes:

• jdk/crac/recursiveCheckpoint/Test
  • Always fails with Process returned unexpected exit code: 136: expected 0 to equal 136 on macOS/x64, same in openjdk/crac
  • Marked as problematic in afd6817
• runtime/CommandLine/PrintClasses.java#id1, serviceability/dcmd/compiler/CodeHeapAnalyticsParams
  • Sometimes hit a timeout (even an unreasonably large one) on Linux
  • Marked as problematic in bb2007c
• CRaC tests that use CRIU
  • Sometimes encounter CRIU-related errors, especially frequently on Linux/x86
  • Marked as problematic in bb2007c

This assert fails when trying to portable-restore the following code checkpointed on Main::work() with BCI 9 or 36 to be executed next:

public class Main {
    private static boolean work() {
        double result = 0;
        long time = System.currentTimeMillis();
        for (long i = 0; i < 99999999L; i++) {
            result = i / result + time * i;
        }
        return result % 2 == 0;
    }

    public static void main(String[] args) throws Exception {
        int counter = 0;
        while (true) {
            var result = work();
            System.out.print(counter + (result ? " " : "  "));
            Thread.sleep(800);
            System.out.println(counter++ + (result ? " " : "  "));
        }
    }
}