TDA 3.2: A Swing Thread Dump Analyzer That Now Also Speaks MCP
TDA - Thread Dump Analyzer (for Java). Analyze your Thread Dumps with a GUI or use it as MCP Server.
At a glance
- What is it?
- TDA parses Java thread dumps and heap histograms in a desktop GUI, and since 3.0 it can also run headless as an MCP server for AI tooling. The catch is that its JSON dump support is explicitly marked experimental and thinner than its text parsing.
- Who is it for?
- Adopt TDA if you already have textual thread dumps from logs and want an offline desktop tool that also detects carrier thread pinning and long-running threads. Do not adopt it as your only path if your dumps come from jcmd in JSON format, because the README states those lack thread states and native IDs.
- Can I use it commercially?
- Yes, with conditions. LGPL-2.1 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Java, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap TDA fills between jstack output and a running profiler
A thread dump is cheap to capture and awkward to read. You get a wall of stack traces, and the interesting part is usually the relationship between dumps taken minutes apart, not the contents of any single one. TDA is built around that comparison. The README describes parsing multiple thread dumps from log files and displaying them in a tree structure, with a find-long-running-threads feature that compares consecutive dumps to see which threads have not moved. That is the core workflow: collect dumps into a log, load the log, and look for stacks that repeat.
The audience is narrow and identifiable. It is a Java engineer holding a production log file, working offline, who cannot attach a profiler to the process. The README calls this the most common way to use TDA: offline analysis of production log files. It also runs as a JConsole or VisualVM plugin, so the same analysis is available while attached to a live JVM, but the offline case is the one the project leads with.
TDA is not a sampler and does not collect anything on its own. It reads what you already have. That distinction matters when you compare it against anything that attaches to a JVM and produces its own data.
Parsing, statistics, and the pinning detection added in 3.0
The mechanism is file-in, tree-out. You add log files containing thread dumps, TDA parses them, and it displays the result in a tree view. On top of that it computes statistics about thread states, monitors, and waiting or locking threads, and it performs automatic deadlock identification with monitor details. Class histogram analysis is included for heap objects produced with -XX:+PrintClassHistogram, which means the same tool covers a second class of input beyond thread dumps.
One parsing detail is worth calling out because it solves a real annoyance. Thread dumps frequently carry no timestamp, so TDA lets you supply a regular expression to correlate dumps with log entries. If your dumps are interleaved with application log lines that do have timestamps, that regex is how you get a usable timeline instead of an undated list.
Version 3.0 extended the MCP server with carrier thread pinning detection and support for SMR (Safe Memory Relocation) parsing. Pinning is the specific failure mode of virtual threads: a virtual thread that blocks inside a synchronized block or a native call pins its carrier thread, and the symptom is a starved scheduler rather than a deadlock. TDA's virtual thread support covers virtual thread states, pinning issues, and carrier thread relationships, per the feature list. That is a more targeted capability than generic virtual thread counting, and it is the strongest reason to prefer a current release over an older one.
3.1 added UTF16 logfile parsing, which matters if your log pipeline emits UTF16 and you were previously converting files by hand before loading them.
Running it: the JAR, the plugins, and the MCP server
The simplest path is the self-contained JAR from the Releases page. The README gives this command:
java -Xmx512m -jar tda.jar
It notes that with several or large log files you may need to raise the -Xmx value. That is the only tuning knob documented for the standalone case, and it is a real constraint: parsing many dumps in one session is memory-bound, and 512 MB is presented as a starting point rather than a ceiling.
For VisualVM, TDA is available in the Plugin Center under Tools, then Plugins, but the README states the last version available there is 2.4. To get a recent version you download the three nbm files from the Releases page and install them manually through the VisualVM plugin settings. Both the 3.1 and 3.2 release notes list proper VisualVM integration as an item, which suggests this integration has needed repeated attention across releases.
On macOS there is a DMG that bundles its own Java runtime, so no separate JDK is required. The build is unsigned, so Gatekeeper blocks the first launch. The documented workaround is to right-click or Control-click TDA.app in Applications, choose Open, and confirm the dialog; after that first launch it opens normally. If that fails, the README points to the '?' icon in the error dialog for further system settings steps.
The MCP server mode is the newest surface. The feature list describes it as headless analysis for integration with AI tools including Cursor, Junie, and Claude Desktop, and 3.0 added logging specifically for troubleshooting in MCP mode. That logging addition is a signal: headless mode needed diagnosability work, which is typical for a server path bolted onto a desktop application.
JSON thread dumps are the weak spot, and the README says so
The clearest limitation is documented by the project itself. TDA can parse JSON-formatted dumps created with:
jcmd <pid> Thread.dump_to_file -format=json <file>
But the README states plainly that JSON dumps currently provide basic information (name, tid, stack trace) and lack details like thread states or native IDs, and that for comprehensive analysis textual dumps are recommended. This is not a minor caveat. Thread states are what the statistical analysis and the state-based filters operate on. If your dumps are JSON, you lose the statistics layer, the deadlock view's context, and much of the value of comparing dumps over time. The feature is labeled experimental in the README's own heading.
If your environment standardized on jcmd JSON output, TDA is the wrong tool for the full job today. You would be using it as a stack trace viewer. Generating text dumps instead (jstack, or jcmd Thread.print) is the path that unlocks the rest of the tool.
A second boundary is the heap side. Class histogram analysis depends on -XX:+PrintClassHistogram, a flag that is not enabled by default and that you have to have planned for before the incident. TDA cannot recover heap data that was never printed.
A third is currency of the plugin path. The Plugin Center lag at 2.4 means the convenient install route does not deliver the 3.x features, including the pinning detection. You have to do the manual nbm install to get them.
How TDA differs from attaching a live profiler
The obvious alternative is a live diagnostic tool: VisualVM on its own, JConsole, or a sampling profiler that attaches to a running JVM. The difference in approach is where the data comes from. A profiler attaches to the process, samples it continuously, and can show you CPU and allocation hot paths over time. TDA reads a file you already captured and reconstructs a picture from a small number of snapshots.
That makes the two tools answer different questions. A profiler tells you where time is going right now. TDA tells you what a set of dumps taken at intervals have in common, which is how you find a thread that has been stuck in the same frame across every capture. The long-running thread detection is a cross-dump comparison, and no single-snapshot profiler view gives you that directly.
The trade-off is resolution. TDA sees only what the dump format contains. Sampling profilers see more, but they require attaching to a process, which in production is often the thing you cannot do. TDA's offline posture is the point, not a shortcoming.
Worth noting: TDA itself installs into VisualVM and JConsole as a plugin, so the comparison is not strictly either-or. You can run the profiler and load TDA's views inside it. The manual nbm installation step is the friction in that arrangement.
Licence and the cost of keeping up with Java releases
TDA is licensed under LGPL-2.1. For most teams using it as a standalone desktop tool, that is unremarkable. It becomes relevant if you embed it, ship a modified version, or link it into a product, because the LGPL carries obligations around the library itself that differ from permissive licences. That is a question for your own legal review, not something to settle from a README.
On maintenance, the release cadence visible in the material is roughly one release every few months: 3.0 in January 2026, 3.1 in April, 3.2 in May, with the repository still active as of September 2026. The 3.2 notes are small: VisualVM plugin integration and a jsvg version bump. That is a maintenance release, not a feature release, and it tells you the project is in a steady state rather than rapid expansion.
The upgrade cost sits mostly in the Java version treadmill. TDA claims support from Java 1.4.x through Java 21+, with virtual thread support from Java 19+ and JSON dumps from Java 21+. Each new JDK brings new dump formats and new thread semantics, and the 3.0 notes show the project absorbing two of them at once (pinning, SMR parsing). If you run a recent JDK, you want a recent TDA; the plugin center's 2.4 will not have the 3.x work.
There is no dependency burden to manage on your side. The JAR is self-contained and the macOS build bundles its own runtime. The Renovate badge in the README indicates automated dependency updates in the repository, which is about the maintainer's process, not yours.
Who should take it, and what to confirm before you do
Take TDA if you routinely capture textual thread dumps into log files and need an offline way to compare them, detect deadlocks, and spot threads that never move. Take it with more confidence if you are on Java 19 or later and care about virtual thread pinning, because that detection arrived in 3.0 and is the clearest differentiator against older analyzers. Take it if you want the same analysis available inside VisualVM or JConsole rather than as a separate window.
Skip it, or use it only as a stack trace viewer, if your dumps come from jcmd in JSON format and you need thread states. Skip it if you need continuous live profiling; it reads snapshots, it does not sample.
Before you commit, check three things. Confirm your dump format is textual, since that is the format the README recommends for comprehensive analysis. Confirm the VisualVM plugin version you need, because the Plugin Center still serves 2.4 and 3.x requires the three nbm files installed manually. And if you are on macOS, confirm the unsigned DMG install path works on your machine before you standardize on it, since the first launch requires the right-click Open workaround and a fallback through system settings.
The project's own recommendation is the deciding fact here: for comprehensive analysis, textual dumps are recommended. Build your dump collection around that, and TDA 3.2 does the rest of the job offline.
Editorial conclusion
Adopt TDA if you already have textual thread dumps from logs and want an offline desktop tool that also detects carrier thread pinning and long-running threads. Do not adopt it as your only path if your dumps come from jcmd in JSON format, because the README states those lack thread states and native IDs. Before committing, verify that the VisualVM plugin version you need is installable: the plugin center still lists 2.4, so 3.x requires the three nbm files from the Releases page installed manually.
Community notes