How does this skill differ from manually checking heap dumps?

This skill automates the detection of Java memory leaks by performing multi-step histogram delta analysis and JFR profiling, effectively distinguishing between genuine leaks and temporary spikes in garbage collection.

What are the specific technical requirements for running this skill?

The skill requires JDK 8u262+ or 11+ and depends on the javaperf MCP server being installed on the same host and under the same OS user as the target JVM.

Is it safe to run this skill on a production JVM?

Yes, it utilizes JFR (Java Flight Recorder) old object sampling and managed heap dumping, specifically designed to capture diagnostics while minimizing the performance impact on production environments.

Which AI agents or frameworks can I use this skill with?

It is compatible with any AI agent or platform that supports the Model Context Protocol (MCP) and can interface with the javaperf server on your local machine.

What exactly is included in the purchase?

You receive the specialized agent skill configuration, which includes the logic for multi-step differential analysis, GC efficiency tracking, and retention hypothesis generation.

Can I use this skill to debug a JVM running on a remote server?

No, this skill requires the MCP server to be on the same host as the JVM; it currently does not support remote attachment or monitoring across different network nodes.

javaperf memory leak

I have analyzed the heap histogram deltas and JFR old object samples for PID 4502 over a 60-second window. The data shows a consistent growth in com.example.session.UserSession objects that are not being reclaimed.

Leak Analysis for PID 4502

Class Name	Δ Instances	Δ Bytes	Consistent?
`com.example.session.UserSession`	+1,420	+227,200	Yes (3/3)
`java.util.concurrent.ConcurrentHashMap$Node`	+1,420	+45,440	Yes (3/3)
`char[]`	+2,840	+181,760	Yes (3/3)

Allocation Origin:
JFR profiling shows these objects are instantiated via com.example.auth.SessionManager.createSession during incoming HTTP requests.

Retention Hypothesis:
The UserSession objects are being added to a static ConcurrentHashMap inside SessionManager. While a cleanup task exists, the GC efficiency report shows par new and concurrent mark sweep cycles are reclaiming 0% of these specific instances, suggesting the "remove" logic is failing or the TTL is effectively infinite.

Confidence: High. The instance count for the Map nodes exactly matches the UserSession growth.

Next steps

Inspect SessionManager.java at line 84 to verify the eviction policy on the static map.
Check if SessionExpiredEvent listeners are correctly removing entries.
If the code looks correct, run heap_dump to confirm the exact GC root path in Eclipse MAT.

About this skill

Hunts Java memory leaks by comparing live heap histograms over time, recording old-object samples, and building a retention hypothesis, with an optional heap dump for Eclipse MAT, via the javaperf MCP server. Use when the user says heap keeps growing, memory never comes back after GC, the app OOMs after hours or days, or asks to find a memory leak.

Frequently Asked Questions

javaperf memory leak