Heap-dump analysis
for AI agents.
deepheap analyzes Java HPROF heap dumps, thread dumps, and GC logs through MCP. AI clients query classes, retained sizes, GC roots, dominator paths, off-heap memory, and threads.
HPROF parser designed for heap dumps much larger than available RAM. The full file is never loaded into memory; analysis structures scale with dump complexity rather than file size.
Every analysis is an MCP tool call. Works with Claude (Desktop/Code), Cursor, VS Code, Copilot, Gemini CLI, Codex, and any MCP-capable client. No GUI, no IDE plugin, no proprietary query language.
deepheap returns structured facts: class counts, retained sizes, GC root paths, object fields. The AI interprets them in context. The engine does not hallucinate heap data.
From question to root cause
Connect your AI client, load a dump, and ask. deepheap picks the right tools and returns structured data. The AI synthesizes the answer.
ConcurrentHashMap field on a MetricsRegistry singleton, holding 2.1 GB across 184,000 MeterSnapshot entries. The GC root path shows the registry is reachable through a static field on ApplicationContext, so it stays alive for the life of the process. The growth pattern points to unbounded cardinality: meter entries accumulate as new endpoints are hit, with nothing evicting them. Worth checking for a meter filter to cap cardinality, or a bounded registry implementation.Illustrative transcript. Class names are generic; actual tool results vary by dump.
Things you can ask
What runs where
Everything runs locally. The MCP server exposes structured tool results; the AI client synthesizes the answer. String content is filtered before it reaches the model.
The AI client receives only structured tool results. String content is filtered by default, not passed raw to the model.
Why not Eclipse MAT or VisualVM?
- headless + scriptable No desktop session required. Run analysis from CI, remote hosts, or inside a container: anywhere your AI client runs.
- no context switch The answer lives inside the LLM session you're already in. No manual hunting for information, no copy-pasting object IDs, no separate query language to learn.
- dumps > RAM The full file is never loaded into memory, and the largest derived indexes are memory-mapped to disk rather than held on the heap. Footprint scales with object count, not file size, so dumps far larger than available RAM are routine.
- multi-surface One tool covers HPROF heap dumps, thread dumps, and GC logs. Correlate a GC pause pattern in the log with object retention in the dump in a single session.
Headline tools
35 MCP tools cover heap analysis, thread inspection, and GC log diagnosis. Three that come up in almost every session:
Supported formats
Heap dumps (HPROF)
- Any HotSpot-derived JDK (OpenJDK, Temurin, Oracle JDK, Corretto, Zulu, etc.), plus Azul Zing / Platform Prime
- JDK 8 and later
- Uncompressed and multi-block gzip (
.hprof.gzfrom jcmd or jmap, including Zing's), read with no decompression to disk
Thread dumps
- jstack text format
- JEP 425 JSON format (JDK 21+)
GC logs
- Unified logging (JDK 9+) and pre-unified (JDK 8)
- gzip-compressed files
- G1, Parallel, Serial, CMS (removed in JDK 14, logs still parse), ZGC, Shenandoah
JVM language collections
- Java standard collections
- Kotlin, Scala, Groovy
- Other JVM languages render as their underlying Java types
The dump stays on your machine
byte[], char[], and related buffer, replacing the content with a closed-vocabulary format label (json-object, uri, jwt, pem, base64, …) before the result is returned. Heap content can't smuggle natural-language instructions into the AI. Override with --show-strings when you control and trust the dump. More on the redaction model →