mcp-jvm-diagnostics 0.1.8 → 0.1.10

package/build/analyzers/contention.js

@@ -47,14 +47,22 @@ export function analyzeContention(threads) {
         recommendations.push("Multiple contention hotspots detected. Consider redesigning synchronization — ConcurrentHashMap, read-write locks, or lock-free data structures may reduce contention.");
     }
     // Check for thread pool exhaustion
-    const poolPatterns = ["pool-", "http-", "exec-", "ForkJoin", "worker-"];
-    for (const pattern of poolPatterns) {
+    const platformPoolPatterns = ["pool-", "http-", "exec-", "ForkJoin", "worker-"];
+    for (const pattern of platformPoolPatterns) {
         const poolThreads = threads.filter(t => t.name.includes(pattern));
         const poolBlocked = poolThreads.filter(t => t.state === "BLOCKED");
         if (poolThreads.length > 0 && poolBlocked.length > poolThreads.length * 0.5) {
             recommendations.push(`Thread pool "${pattern}*" has ${poolBlocked.length}/${poolThreads.length} threads BLOCKED — pool exhaustion risk. Consider increasing pool size or reducing lock hold time.`);
         }
     }
+    // Virtual thread schedulers (Java 21+ VirtualThreadScheduler, Kotlin coroutines DefaultDispatcher).
+    // BLOCKED/WAITING state in these pools does not exhaust OS carrier threads — add a caveat instead
+    // of triggering the same exhaustion warning.
+    const virtualPoolPatterns = ["VirtualThreadScheduler", "DefaultDispatcher"];
+    const hasVirtualPool = threads.some(t => virtualPoolPatterns.some(p => t.name.includes(p)));
+    if (hasVirtualPool) {
+        recommendations.push("Virtual thread pool detected. BLOCKED and WAITING states do not exhaust OS carrier threads — monitor task queue depth and carrier thread saturation instead.");
+    }
     // Check for WAITING threads that might indicate starvation
     const waitingCount = threads.filter(t => t.state === "WAITING").length;
     if (waitingCount > totalThreads * 0.7) {

package/build/index.js

@@ -13,7 +13,7 @@ import { parseJfrSummary } from "./parsers/jfr-summary.js";
 import { generateReportFromThreadDump, analyzeThreadDumpMarkdown, } from "./reporting.js";
 // Handle --help
 if (process.argv.includes("--help") || process.argv.includes("-h")) {
-    console.log(`mcp-jvm-diagnostics v0.1.8 — MCP server for JVM diagnostics
+    console.log(`mcp-jvm-diagnostics v0.1.9 — MCP server for JVM diagnostics
 
 Usage:
   mcp-jvm-diagnostics [options]
@@ -33,7 +33,7 @@ Tools provided:
 }
 const server = new McpServer({
     name: "mcp-jvm-diagnostics",
-    version: "0.1.8",
+    version: "0.1.9",
 });
 // --- Tool: analyze_thread_dump ---
 server.tool("analyze_thread_dump", "Parse a JVM thread dump (jstack output) and analyze thread states, detect deadlocks, identify lock contention hotspots, and find thread starvation patterns. Handles both platform threads and virtual threads (Java 21+). Note: deadlock detection covers synchronized monitor locks only — java.util.concurrent.locks.ReentrantLock and other j.u.c lock types do not expose their waiters in thread dump lock info and will not be detected.", {
@@ -345,15 +345,15 @@ server.tool("analyze_jfr", "Parse JDK Flight Recorder summary output and analyze
     }
 });
 // --- Tool: diagnose_jvm ---
-server.tool("diagnose_jvm", "Unified JVM diagnosis combining thread dump and GC log analysis. Provide one or both inputs for comprehensive root cause analysis.", {
+server.tool("diagnose_jvm", "Unified JVM diagnosis combining thread dump and GC log analysis with cross-correlation. Detects deadlocks, lock contention, GC pressure, and GC-induced cascading thread blocks. When both inputs are provided from the same time window, cross-correlates high GC overhead with contention and flags long GC pauses causing thread starvation. Either input can be omitted for single-source analysis.", {
     thread_dump: z
         .string()
         .optional()
-        .describe("Thread dump text (from jstack)"),
+        .describe("Thread dump text (from jstack, kill -3, or VisualVM). Capture at the same time as the GC log for accurate cross-correlation."),
     gc_log: z
         .string()
         .optional()
-        .describe("GC log text (from -Xlog:gc*)"),
+        .describe("GC log text (from -Xlog:gc* for Java 9+, or -verbose:gc for Java 8). Capture at the same time as the thread dump for accurate cross-correlation."),
 }, async ({ thread_dump, gc_log }) => {
     try {
         if (!thread_dump && !gc_log) {

package/build/parsers/heap-histo.js

@@ -56,7 +56,9 @@ export function parseHeapHisto(text) {
         });
         return { entries, totalInstances, totalBytes, issues, recommendations };
     }
-    // Analyze top entries for suspicious patterns
+    // Analyze top entries for heap-percentage-based issues.
+    // These checks are only meaningful near the top of the list — a class that doesn't
+    // rank in the top 30 by bytes cannot be consuming >10% of heap.
     for (const entry of entries.slice(0, 30)) {
         const pctBytes = totalBytes > 0 ? (entry.bytes / totalBytes) * 100 : 0;
         const isJdkInternal = JDK_INTERNALS.has(entry.className);
@@ -69,6 +71,20 @@ export function parseHeapHisto(text) {
             });
             recommendations.push(`Investigate ${entry.className} — use Eclipse MAT or VisualVM to trace retention paths. Check for unbounded caches or collections.`);
         }
+        // Char arrays ([C) or byte arrays ([B) dominating — usually String-related
+        if ((entry.className === "[B" || entry.className === "[C") && pctBytes > 40) {
+            issues.push({
+                severity: "WARNING",
+                message: `${entry.className === "[B" ? "Byte" : "Char"} arrays consume ${pctBytes.toFixed(1)}% of heap — likely driven by String retention. Check for large string caches or log buffering.`,
+                className: entry.className,
+            });
+        }
+    }
+    // Instance-count checks scan all entries: a class ranked outside the top 30 by bytes
+    // can still have an excessive number of small instances (e.g., many small DTOs or events).
+    for (const entry of entries) {
+        const pctBytes = totalBytes > 0 ? (entry.bytes / totalBytes) * 100 : 0;
+        const isJdkInternal = JDK_INTERNALS.has(entry.className);
         // Very high instance count for non-JDK class (> 100K)
         if (entry.instances > 100_000 && !isJdkInternal && pctBytes <= 10) {
             issues.push({
@@ -86,14 +102,6 @@ export function parseHeapHisto(text) {
             });
             recommendations.push("Replace finalize() with Cleaner or try-with-resources. Finalizers delay GC and can cause memory pressure.");
         }
-        // Char arrays ([C) or byte arrays ([B) dominating — usually String-related
-        if ((entry.className === "[B" || entry.className === "[C") && pctBytes > 40) {
-            issues.push({
-                severity: "WARNING",
-                message: `${entry.className === "[B" ? "Byte" : "Char"} arrays consume ${pctBytes.toFixed(1)}% of heap — likely driven by String retention. Check for large string caches or log buffering.`,
-                className: entry.className,
-            });
-        }
     }
     // Check for class loader leak indicators
     const classCount = entries.find(e => e.className === "java.lang.Class");

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mcp-jvm-diagnostics",
-  "version": "0.1.8",
+  "version": "0.1.10",
   "description": "MCP server for JVM diagnostics — analyze thread dumps, detect deadlocks, parse GC logs, and get JVM tuning recommendations",
   "mcpName": "io.github.dmitriusan/mcp-jvm-diagnostics",
   "author": "Dmytro Lisnichenko",