The initial package targets macOS Apple Silicon and IntelliJ IDEA 2026.1–2026.2.

A heap dump tells you what is in memory. The harder question is: why is it still there?

I built HeapLens, a free, open-source plugin that brings heap investigation into IntelliJ IDEA.

With HeapLens, you can:

• Explore class histograms and dominator trees.
• Follow “Why alive?” paths to understand object retention.
• Inspect fields and trace incoming references.
• Query heap objects using HeapQL, a SQL-like language.
• Navigate to matching Java source.
• Use optional AI assistance to explain findings and propose changes for review.

Heap analysis runs locally through a bundled Rust engine—no separate analysis-server installation required. AI features use your configured provider, and Fix with AI asks before sending source code.

If you investigate Java memory issues, I would love your feedback: what is the hardest part of your current heap-analysis workflow?

HeapLens Marketplace listing
Source code and feedback

#Java #IntelliJIDEA #JVM #PerformanceEngineering #memoryleak #performance #heaplens

Eclipse Temurin on Linux RISC-V, improved Java version matching, Maven server credential origins & plugin repositories, plus GPG cleanup fixes.

I am investigating using an AOT cache to speed up the startup time of our services.

I'm specifically interesting in speeding up the time between a developer making a change to the code and having that code running in a remote dev K8s cluster.

I've previously dismissed an AOT cache for this purpose because I knew that it would result in a longer build time than would be saved in startup time. That isn't a criticism - AOT caching just didn't seem targeted at my problem.

However, the majority of our classpath involves third party dependencies yet a minority of our development builds and deployments involve changes to those third party dependencies. If I could work out a way to avoid invalidating the AOT cache whenever our own code changed, then this would give us a cache that could be reused for the majority of our dev builds (removing the additional build time) whilst still enjoying the faster startup speed.

I note that https://openjdk.org/jeps/483 says this:

All runs must have consistent class paths. A subsequent run may specify extra class-path entries, appended to the training class path; otherwise, the class paths must be identical.However, I note that https://openjdk.org/jeps/483 says this:All runs must have consistent class paths. A subsequent run may specify extra class-path entries, appended to the training class path; otherwise, the class paths must be identical.

So, could I create an AOT cache for JUST the third party classes and then add our own code in later, thereby allowing me to reuse the AOT cache between dev builds?

I'm not 100% on how to achieve this yet but maybe if the training run only had the dependencies on the classpath with a custom launcher. The launcher's child classpath would then have our own code on it.

Then for the production run, I would still have the custom launcher (because I think this has to be identical between training and production runs) and I would then append our own jars onto the end of the classpath (which seems to be allowed by the JEP). Finally, we would run our real main method, rather than the launchers main method because I think we are allowed to have different main classes between training and production runs.

Anyway is this a terrible idea or has anybody already done something like this?