Topview Motion StudioGet a launch video for about $3, not thousands
Promoted
ThreadMine
JVM thread dump analyzer that catches Loom pinning
14 followers
JVM thread dump analyzer that catches Loom pinning
14 followers
ThreadMine turns a JVM thread dump into an answer in seconds. Paste or upload one — free, no signup — and it auto-detects deadlocks, thread leaks, pool exhaustion, CPU hotspots, and virtual thread pinning (Project Loom), with an A–F health score. The AI assistant, Vein, explains the root cause in plain language and suggests the fix. It reads HotSpot, OpenJ9, Zing and GraalVM. The thing others miss: virtual-thread pinning detection.
Maker here 👋 I'm Felipe, I built ThreadMine.
It started as an itch: I kept reading JVM thread dumps by hand during incidents, and the worst one to catch by eye is virtual thread pinning — your Loom app quietly turns back into a bounded thread pool and nothing in the logs tells you. So I built the reader I wanted: paste a dump, get the problems named, with a health score and a shareable link.
Free, no login: upload up to 10 MB, automatic detection (deadlock, thread leak, pool exhaustion, CPU spikes, Loom pinning), health score, shareable report. Paid tiers add the AI explanations (Vein), history, multi-dump comparison and integrations.
New this week: there's an MCP server, so your coding agent can read a thread dump itself. Install:
npx @threadmine/mcp
"Why is prod hanging?" → it pulls the dump, gets the analysis back, and tells you which lock is the problem. That one surprised me — it's the use case I didn't design for and now use the most.
Straight about privacy since people ask: the dump is uploaded and processed server-side (not in your browser), over TLS, encrypted at rest, kept temporarily and deletable on demand, with zero retention on the AI side.
I'd genuinely love for you to throw a real production dump at it and tell me where it's wrong — especially edge cases in OpenJ9/Zing parsing or the pinning detector. Happy to answer anything here.
PS: `PRODUCTHUNT` takes 30% off the first payment, if you want it.
Would love to see a diff view that compares two dumps side by side so you can spot exactly what changed between a healthy run and a broken one. That would make it way easier to pinpoint regressions after a deploy without scrolling through timestamps manually.
@ceylinrekl61430 Good news — comparison is already in there (Pro tier): you upload a sequence of dumps and it tracks what changed between snapshots — threads appearing/disappearing, state transitions, locks accumulating waiters. The specific framing you describe — a side-by-side "healthy run vs broken run" diff — is more two-column than what I render today, and honestly it's a better mental model for post-deploy regressions. Noted. Out of curiosity: what would you want highlighted first in that diff — thread states, lock owners, or pool utilization?
the way it flags virtual-thread pinning alongside the usual deadlock and pool exhaustion checks feels like real engineering empathy for anyone running on Loom.
@ceylinpvmw Thank you — pinning is genuinely why I built this. It's the quietest failure mode I know: your Loom app just becomes a bounded thread pool again and nothing in the logs says so. If you're running virtual threads in production, I'd love to see what your dumps look like — the detector has had the most tuning on HotSpot, and real-world edge cases are gold for it.