CratonVM

A Java Virtual Machine written in Rust, with a custom x86-64 JIT and an opt-in automatic GPU fast path for a documented subset of Java kernels.

CratonVM boots against a real JDK when one is present (JAVA_HOME, CRATONVM_JAVA_HOME, or java on PATH) and runs fully standalone when it isn't — its own Rust implementations of the Java standard library mean no JDK install, no rt.jar, one self-contained binary.

Highlights

• Custom x86-64 JIT — tiered compilation (interpreter → C1 → C2), OSR, LICM, bounds-check elimination, AVX2 SIMD, precise stack maps. Experimental AArch64 backend.
• Automatic GPU fast path — supported pure static array kernels can run on NVIDIA GPUs without API changes. Eligibility is intentionally narrow and unsupported shapes fall back to CPU (see below).
• ZGC by default. The default collector is a memory-backed, stop-the-world ZGC (-XX:+UseZGC). It has thread-local allocation buffers that the JIT allocates from inline, and parallel sliding compaction (kill switch CRATONVM_ZGC_RELOCATE=0).
  • Parallel marking (CRATONVM_ZGC_PARMARK=<workers>), concurrent marking (CRATONVM_ZGC_CONC_START) and a generational mode (CRATONVM_ZGC_GENERATIONAL=1) are opt-in.
  • The colored-pointer load barrier is built but not yet armed.
  • -XX:+UseGenerationalGC selects the young/old collector with a Cheney moving young generation; a cycle that cannot prove complete root coverage falls back to a non-moving sweep.
  • Region-based G1 is experimental and opt-in (-XX:+UseG1GC).
  • See ARCHITECTURE.md.
• Real frameworks run — Spring, Spring Boot, Tomcat, Netty, Hibernate, Hibernate Reactive, H2 Database, Postgres driver boot and pass large test suites.
• Rust implementation — Rust removes many ambient memory hazards, but the VM, JIT, GC, FFI, I/O, AWT, CUDA, and JFR contain reviewed and still-being- audited unsafe regions. See SECURITY.md.
• JNI & embedding — JNI Invocation API, a stable C-ABI library (libcratonvm), and a Rust facade (cratonvm-embed).
• Observability & hardening — Java Flight Recorder, bytecode verification, opt-in I/O confinement and network egress policy (docs/SECURITY_HARDENING.md).

Performance

CPU, vs HotSpot JDK 25 C2 — same flags both sides, checksum-verified against HotSpot on every run (zero mismatches):

‡ Measured under G1 (-XX:+UseG1GC); HashMap and String/Regex measured under default ZGC (-XX:+UseZGC) (best-performing collector shown per workload). All rows run in default strict mode (--jdk-only), isolated fresh process per measurement; see BENCHMARK.md for full multi-configuration data across both collectors and all sizes.

Full per-size data, checksums, CV, and the ZGC-vs-G1 delta are in BENCHMARK.md.

GPU offload, vs HotSpot C2 and TornadoVM 4.0.1 (RTX 2060, N = 2²⁴, warm, full H2D+kernel+D2H round-trip, checksums bit-identical to HotSpot):

Unlike TornadoVM, the supported automatic path needs no @Parallel annotations or TaskGraph API — within a deliberately narrow eligibility subset, not a general promise that arbitrary Java runs on the GPU. Full results, extra sizes, and methodology: BENCHMARK.md and docs/gpu/README.md.

What to build on

Boots, runs, and passes large real-world test suites:

• Spring 7.1 / Spring Boot 4.2
• Tomcat 12.0 / Netty 4.2
• Hibernate ORM 7.4 / Hibernate Reactive 4.5
• H2 DB 2.4 / PostgreSQL driver 42.7
• Apache Commons Math 4.0
• Bouncy Castle Java 1.86

Just because it boots and runs large real-world test suites does not mean it is production-ready. But you can start building on it focusing on its main strength - the gpu performance.

Java Version Support

Quick Start

Build (Rust 1.88+):

cargo build --release -p cratonvm-cli

Compile and run a class:

javac HelloWorld.java
./target/release/cratonvm -cp . HelloWorld

Run a JAR:

./target/release/cratonvm --jar app.jar

Bigger heap, G1 collector, program arguments:

./target/release/cratonvm -Xmx4g -XX:+UseG1GC -cp "classes:lib/util.jar" com.example.Main arg1 arg2

Command-Line Reference

cratonvm [OPTIONS] <CLASS_NAME> [ARGS]...
cratonvm [OPTIONS] --jar <FILE.jar> [ARGS]...

Every command above is verified against the current binary. --gpu and the other GPU options require a --features gpu-driver build — see docs/gpu/README.md.

JDK-only mode — the default since 2026-09-20

The VM treats real JDK class bytes as authoritative: it will not fabricate a class that has no real bytes, and it will not register or invoke a synthetic-stub native. Enforcement is at wave 1 (class fabrication and stub registration enforce; the rest is recorded and counted), so a program that depends on a substitution may fail here and pass under --compatible. That difference is the measurement, not a bug in either mode.

A/B a program to see what it depends on:

./target/release/cratonvm -cp . MyApp                       # default: jdk-only
./target/release/cratonvm --compatible -cp . MyApp          # pre-2026-09-20 behaviour
./target/release/cratonvm --jdk-only-report report.json -cp . MyApp

The report works in either mode: under --compatible it is a census of what strict mode would reject.

Details: docs/jdk-only-migration.md (operator guide); the rest of the JDK-only docset is indexed from docs/README.md.

Limitations

• AWT/Swing are headless (no on-screen rendering); JavaFX is out of tree.
• Reflection and JNI cover the common paths; some edge cases (C-varargs JNI forms, full foreign-thread attach) are partial.
• Cryptography is best-effort and not constant-time everywhere — see docs/CRYPTO_STATUS.md.

Documentation

• Complete manual — installation, use, compatibility, security, performance, operations, embedding, architecture, contributing, and reference
• Documentation index — map of maintained standalone and manual references
• ARCHITECTURE.md — crate layout and subsystem design
• BENCHMARK.md — benchmark methodology and full results
• Performance tuning — measurement-first tuning workflow
• Deployment and operations — packaging, sizing, security boundaries, rollout, and rollback
• Incident response — crash/hang/OOM/wrong-result diagnostic runbook
• Runtime lifecycle and runtime contracts
• docs/GC.md — collectors, barriers, heap layout
• docs/JIT_OPTIMIZATION.md — the JIT optimization journey
• docs/gpu/README.md — GPU offload reference
• docs/EMBEDDING.md — embedding CratonVM in your application
• docs/SECURITY_HARDENING.md — sandboxing and hardening
• docs/CONFIG.md — configuration reference
• docs/jdk-only-migration.md — --jdk-only operator guide; the rest of the JDK-only docset is indexed from docs/README.md

Building & Testing

cargo build --release          # full workspace
cargo test --workspace         # unit + integration tests
bash regression-suite/run.sh   # fast HotSpot-differential regression suite

Contributing

See CONTRIBUTING.md. Architectural orientation lives in ARCHITECTURE.md; required merge signals are defined by release readiness and the CI workflows.

License

Apache-2.0 — see LICENSE. CratonVM is an independent implementation and is not derived from OpenJDK sources; see THIRD-PARTY-NOTICES.md and TRADEMARKS.md.