---
title: "Discussion on \"Faster Java Pod Startups Without GraalVM: Why AppCDS Needs Kubernetes Image Volumes\" | Hashnode"
description: "Discussion on \"Faster Java Pod Startups Without GraalVM: Why AppCDS Needs Kubernetes Image Volumes\". mnemo-warmup automates AppCDS & Project Leyden AOT on Kubernetes using Image Volumes, cutting Spring Boot startup 40% (5s to 3s) without GraalVM."
url: "https://hashnode.com/posts/faster-java-pod-startups-without-graalvm-appcds-kubernetes-image-volumes/6af516315c88be31c910c9f3"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [Faster Java Pod Startups Without GraalVM: Why AppCDS Needs Kubernetes Image Volumes](https://baokhang.hashnode.dev/faster-java-pod-startups-without-graalvm-appcds-kubernetes-image-volumes?utm_source=hashnode&utm_medium=feed)

mnemo-warmup automates AppCDS & Project Leyden AOT on Kubernetes using Image Volumes, cutting Spring Boot startup 40% (5s to 3s) without GraalVM.

22h ago · 6 min read · baokhang.hashnode.dev  
Read the article

-   [#kubernetes](https://hashnode.com/tag/kubernetes)
-   [#java](https://hashnode.com/tag/java)
-   [#spring-boot](https://hashnode.com/tag/spring-boot)
-   [#devops](https://hashnode.com/tag/devops)
-   [#performance](https://hashnode.com/tag/performance)

## Written by

[BaoKhang](https://hashnode.com/@baokhang)

@baokhang

  
[View profile](https://hashnode.com/@baokhang)

Java Spring/Angular Architect | Agentic AI | Software Engineering

## Responses 2

Markdown supported · ⌘↵ to post

[OneLifeVibe](https://hashnode.com/@onelifevibe)

[15h ago](https://hashnode.com/posts/faster-java-pod-startups-without-graalvm-appcds-kubernetes-image-volumes/6af516315c88be31c910c9f3/comment/6af575f319b458f46816c47e)

The honest results table is what makes this post stand out. Showing Spring Boot at 40 percent faster alongside Jenkins at parity and SonarQube slower is far more useful than a single best case number, and the explanation of why the SonarQube wrapper bypasses the cache turns a surprising result into a design lesson. The init container finding is the part I would stress to teams first: cutting JVM boot time from 3.18s to 1.88s while pod readiness stayed at 5s is a clear reminder to measure pod-to-Ready, not just process start. Curious to see the HPA scale-out study you mention, since cache fetch cost against a remote registry is where this approach will win or lose in production.

[BaoKhang](https://hashnode.com/@baokhang)

[15h ago](https://hashnode.com/posts/faster-java-pod-startups-without-graalvm-appcds-kubernetes-image-volumes/6af516315c88be31c910c9f3/comment/6af575f319b458f46816c47e#reply-6af58089b9b6233d0623ee3e)

Thanks for the read :) You're spot-on about the HPA scale-out test. Local kind runs hide network latency, and simultaneous multi-pod bursts against a remote OCI registry introduce real-world fetch and throttling risks. Measuring how archive size impacts fetch time, alongside our fail-open fallback and layer-caching strategies, is the exact stress test I want to tackle before going beta.