[tae898]

Closes #313 (the CDS archive half; the AOT cache stays opt-in, as the issue plans). Part of #315 and the glue changes of the wheels-only 26.11.1.post1. For users: the JVM wheel's bundled JRE now ships a class-data-sharing archive, so the JVM maps the JDK's classes at start instead of loading and verifying them. No value, API or flag changes. The wheel grows by the size of the archive (below).

What changes: jlink builds a JRE without a CDS archive (the issue found no .jsa in the wheel and -Xshare never set). A new scripts/dump_cds_archive.sh dumps the JVM's default archive as the last step of the JRE build, in Dockerfile.build (Linux) and in build-native.sh (macOS and Windows, which build on their own hosts), after the module and library clean-up and before the JRE is copied into the package. It dumps with -XX:+UseCompactObjectHeaders, the flag src/arcadedb/jvm.py sets at every start: the JVM ignores, without an error, an archive dumped with another setting of it. It also dumps with -Xmx1g so compressed oops are on whatever the RAM of the build host is, and then runs bin/java -Xshare:on -version with the same flags, which fails the build when the archive cannot be used.

Loading: I use the JVM's own default archive location and -Xshare:auto (the JVM default) instead of an explicit -XX:SharedArchiveFile, so there is no flag for start_jvm to add and nothing to get wrong on a path. The JVM looks for the archive by itself and goes on without it when it is missing or was dumped for other settings, and the dump and the start name the same file because they run the same JVM with the same flags. aot.py is untouched: it still treats a user's -Xshare or -XX:SharedArchiveFile as the user's decision. Two limits, both a start without the archive as before: a heap above 32 GB (jvm.py gives the JVM half of the RAM, so a machine with more than 64 GB of RAM) uses another archive name that is not dumped, and the archive holds the JDK's classes only (the engine's jars are checked by absolute path and mtime in an archive, which an installed wheel cannot match). A new paragraph in installation.adoc says so.

Memory: I did not measure it. The archive is mapped, not copied, and it is read-only shared pages, so I expect idle RSS to move, but that is a claim for the later measurement, not a result here.

Tests (tests/test_jvm_cds.py, JVM wheel only, run in every platform and Python leg of test-jvm.yml, Windows and macOS included, on the installed wheel at its install path): the wheel holds a .jsa file; the bundled JVM with the exact arguments start_jvm builds starts with -Xshare:on, and -Xlog:class+load shows java.lang.Object source: shared objects file; a JVM with -XX:-UseCompactObjectHeaders cannot use the archive with -Xshare:on and starts without it with -Xshare:auto, which pins the coupling to the flag in jvm.py. I could not run any of it or the build here (CI only); the evidence is the runs listed below. I did not run test-native.yml for this PR: it changes only the JVM wheel's build and tests.

No speed claim: the measurement is a later laptop A/B (cold first read and idle RSS, the method of the issue), and the untimed profile studies queued for tonight.

🤖 Generated with Claude Code