Dependencies that Bundle Code and Execution

2026-07-01

AI Summary

Existing dependency packages distribute only compiled code and lack execution state, forcing applications to reconstruct runtime state on every launch, which harms startup efficiency. This work proposes LIBCACHE, the first system to distribute execution caches of dependencies as first-class artifacts via package registries such as Maven Central: library maintainers generate caches using test suites and publish them alongside JAR files, and build tools automatically merge all dependency caches into a unified execution cache during application construction. This approach demonstrates that execution caches can serve as distributable units in the software supply chain and achieves broader startup coverage than single-workload caching through multi-dependency cache fusion. Evaluation on three real-world Java projects across 12 workloads shows up to 1.91× faster startup, with 10 out of 12 cases outperforming single-workload caching; Batik, for instance, achieves an average speedup of 1.60×.

Abstract

Applications are built from many dependencies. Each dependency is distributed by package registries but it only contains compiled code and does not ship execution state, so runtimes rebuild that state from scratch on every startup. Execution caching records this preparation result so subsequent starts can skip it, but no existing system publishes execution state to a registry for downstream consumers to reuse. We introduce LIBCACHE, the first system to distribute per-dependency execution caches through a package registry as first-class artifacts alongside compiled code. Each library maintainer produces an execution cache from the library's own test suite and publishes it to Maven Central alongside the JAR. At application build time, LIBCACHE merges all per-dependency caches into a single unified cache that covers the classes exercised across every dependency's test suite. We evaluate LIBCACHE on three real-world Java projects across twelve workloads. LIBCACHE speeds up application startup by up to 1.91x and outperforms a cache built from a single workload in 10 of 12 workloads, with the largest average gain for batik (1.60x vs. 1.27x). Cache production adds 10-47% to build time for applications, and execution caches average 18x the size of the corresponding JAR. Our main contribution is LIBCACHE, which establishes that execution caches are distributable supply chain artifacts and that merging per-dependency caches delivers broader startup coverage than any single observation run.

Problem

• execution caching
• package registry
• dependency
• startup performance
• software supply chain

Innovation

• execution caching
• package registry
• dependency management
• startup optimization
• build-time cache merging