You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You are reviewing **TDA (Thread Dump Analyzer)**, a Java-based desktop application using **Swing**. TDA is designed to parse and visualize complex Java thread dumps to identify deadlocks, resource contention, and performance bottlenecks.
4
+
5
+
## Core Technical Principles
6
+
7
+
### 1. Concurrency & Swing (EDT)
8
+
-**Responsiveness:** Ensure that long-running parsing or analysis tasks are NEVER executed on the Event Dispatch Thread (EDT). Use `SwingWorker` or an equivalent background execution mechanism.
9
+
-**UI Updates:** Ensure all updates to Swing components are wrapped in `SwingUtilities.invokeLater` if triggered from background threads.
10
+
11
+
### 2. Memory & Performance
12
+
-**Large Files:** Thread dumps can be massive (hundreds of MBs). Prefer streaming and incremental parsing over loading entire files into memory.
13
+
-**Object Lifecycle:** Watch for memory leaks in listeners and static collections, especially when opening and closing multiple dump files.
14
+
15
+
### 3. Parsing Logic (The Core)
16
+
-**Accuracy:** The parsing logic for thread states (RUNNABLE, BLOCKED, WAITING) must strictly follow JVM specifications.
17
+
-**Robustness:** Handle malformed or truncated thread dumps gracefully without crashing the UI. Provide meaningful error messages to the user.
18
+
19
+
### 4. Swing UI Best Practices
20
+
-**Look & Feel:** Maintain consistency with existing UI components.
21
+
-**Layouts:** Prefer `MigLayout` or `GridBagLayout` for complex forms to ensure resizability. Avoid absolute positioning.
22
+
-**Accessibility:** Ensure components have appropriate tooltips and mnemonic keys where applicable.
23
+
24
+
## Review Focus Areas
25
+
-**Deadlock Detection:** Double-check the logic that identifies circular dependencies in monitor locks.
26
+
-**Regex Performance:** Ensure that regular expressions used for log parsing are optimized and protected against Catastrophic Backtracking.
27
+
-**Clean Code:** Enforce Java 11+ coding standards (or the specific version TDA uses), focusing on readability and modularity.
28
+
29
+
## Communication Style
30
+
- Be concise and technical.
31
+
- If suggesting a change, explain the impact on performance or thread safety.
Copy file name to clipboardExpand all lines: README.md
+2-1Lines changed: 2 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -112,6 +112,7 @@ The MCP server exposes the following tools:
112
112
|`find_long_running`| None | Identifies threads that remain in the same state/stack trace across consecutive dumps. |
113
113
|`analyze_virtual_threads`| None | Detects virtual threads where the carrier thread is stuck in application code. |
114
114
|`get_native_threads`|`dump_index` (int, required) | Returns a list of all threads in a native method for a specific thread dump. |
115
+
|`get_zombie_threads`| None | Returns a list of zombie threads (unresolved SMR addresses) with timestamps and dump names. |
115
116
|`clear`| None | Resets the server state and clears the internal thread store for a new log file. |
116
117
117
118
#### Troubleshooting
@@ -143,7 +144,7 @@ When you encounter a log file that appears to contain Java thread dumps:
143
144
1. DO NOT try to read or "cat" the entire file if it's large.
144
145
2. Use the `tda-analyzer` MCP toolset.
145
146
3. First, call `parse_log(path="...")` to initialize the analysis.
146
-
4. Use `get_summary()`, `check_deadlocks()`, `find_long_running()`, `analyze_virtual_threads()`, and `get_native_threads()` to perform the analysis.
147
+
4. Use `get_summary()`, `check_deadlocks()`, `find_long_running()`, `analyze_virtual_threads()`, `get_native_threads()`, and `get_zombie_threads()` to perform the analysis.
147
148
5. Provide your insights based on the structured data returned by these tools rather than the raw log text.
148
149
```
149
150
This configuration makes the analysis much faster and significantly reduces token usage.
tools.add(createTool("get_native_threads", "Returns a list of all threads currently in a native method for a specific thread dump.",
97
97
createProperty("dump_index", "integer", "The index of the thread dump as retrieved from get_summary.")));
98
98
99
+
tools.add(createTool("get_zombie_threads", "Returns a list of zombie threads (SMR addresses that could not be resolved to any thread).", newJsonObject()));
.append("<b>Warning:</b> Some SMR addresses could not be resolved to threads. This might indicate issues with properly removing threads from the JVM's internal thread list.")
0 commit comments