Project Leyden: AOT compilation and condensed JVM execution

## Problem

The JVM startup problem is fundamentally a **shift-left problem**: work done at runtime (class loading, verification, compilation) could be done at build time if the execution context is known in advance. GraalVM native-image solves this aggressively via closed-world AOT, but sacrifices dynamic features (reflection, dynamic class loading) and peak throughput.

The question is: **can we get AOT startup benefits without the closed-world restriction?**

## Theoretical Background

**Project Leyden** is OpenJDK's answer — a spectrum of **condensation** techniques that progressively shift runtime work to earlier phases (build time, first-run, install time) without requiring closed-world assumptions.

The theoretical model is **staged computation** (also called multi-stage programming): a program's execution is split into phases, where earlier phases pre-compute what later phases would otherwise compute dynamically. This preserves the open-world semantics of Java while eliminating redundant runtime work.

Leyden introduces the concept of a **condensed JVM**:
- **AOT class loading**: classes are loaded, verified, and linked at build time; stored in a "training data" artifact
- **AOT method compilation**: hot methods identified in a training run are compiled ahead-of-time (unlike GraalVM, this is selective — cold paths remain interpreted)
- **AOT code cache**: compiled native code is stored alongside the application, loaded on startup via memory mapping
- **Premain optimization**: code that runs before `main()` (static initializers, module bootstrap) is pre-executed and frozen

This differs from GraalVM's approach:
| | GraalVM native-image | Project Leyden |
|--|---------------------|----------------|
| World assumption | Closed (all code known at build) | Open (dynamic loading allowed) |
| Compilation | Full AOT, all reachable methods | Selective AOT, hot paths only |
| Reflection | Requires explicit configuration | Works naturally (open world) |
| Peak throughput | ~70-90% of JIT | ~100% of JIT (C2 still active) |
| Startup | ~10-50ms | ~50-150ms (projected) |
| Compatibility | Significant restrictions | Full Java compatibility |

The tradeoff is startup speed vs compatibility: Leyden gives ~80% of GraalVM's startup benefit with ~0% compatibility cost.

## Possible Path

JDK 24+ ships early Leyden features (AOT cache, premain optimization). As these mature, jbundle can integrate them into the build pipeline:

- Training run during build captures execution profile
- AOT artifacts (`.aot` cache, condensed class data) are generated and bundled
- Runtime uses pre-computed artifacts for near-instant class loading and JIT-free hot paths
- Fallback to standard JVM when AOT artifacts are unavailable

This is a **progressive enhancement** — each Leyden feature independently improves startup without requiring all-or-nothing adoption.

## Impact

- Projected startup: ~50-150ms (between AppCDS and CRaC)
- Full Java compatibility preserved (no closed-world restrictions)
- Works with standard OpenJDK (no alternative JDK required)
- Composable with existing optimizations (AppCDS is a subset of Leyden's class pre-loading)

## References

- [Project Leyden — OpenJDK](https://openjdk.org/projects/leyden/)
- [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483)
- [Mark Reinhold — "Toward Condensers" (Leyden design notes)](https://openjdk.org/projects/leyden/notes/03-toward-condensers)
- [JEP draft: AOT Method Compilation](https://openjdk.org/jeps/8335368)
- [Thalinger, 2023 — "Project Leyden: Beginnings" (JVMLS talk)](https://www.youtube.com/watch?v=B1WporW_jUo)
- [Stadler et al., 2024 — "Combining AOT and JIT Compilation in the GraalVM" (comparison context)](https://dl.acm.org/doi/10.1145/3617651.3622987)
- [Würthinger et al., 2017 — "Practical Partial Evaluation for High-Performance Dynamic Language Runtimes"](https://dl.acm.org/doi/10.1145/3062341.3062381)

No repository files, tests, or entry points are identified in the issue. Start by reading the Project Leyden and JEP references, then inspect jbundle's build pipeline to determine where JVM packaging and fallback behavior could fit. Done requires a concrete, repository-specific implementation scope rather than only a theoretical integration proposal.

Written by the indexing model from the issue text.