Back to JetBrains

UI Freezes in JetBrains IDE Plugins and How to Avoid Them

JetBrainsMarch 20, 202653m
Topics44
Introduction to UI Freezes in JetBrains IDE Plugins0:10Understanding the Event Dispatch Thread3:31Background Thread Solutions for Simple Cases5:32Cryptic Freeze Reports Beyond EDT6:30Package Checker Plugin Freeze Example6:30IntelliJ Read-Write Lock Concurrency Model8:01Long Read Actions Blocking Write Access10:32Thread Dump Analysis Tools11:30AI-Powered Freeze Analysis13:31Run Read Action Usage15:00Plugin-Related Freezes16:02Thread Dump Collection and Reporting18:01Plugin Slowdown Notifications19:00Additional Freeze Causes20:32Service Initialization Freezes21:31Non-Cancellable Long Read Actions22:00Read-Write Lock Blocking Visualization24:02Simplified Problem Code24:30Non-Blocking Read Action Solution25:32Handling Long Computations27:00Proper Cancellation with ProgressManager28:01ProcessCanceledException29:32Coroutine Read Action API30:02Key Principle: Background Does Not Equal Safe30:32Critical Takeaway31:30AI Assistance for Platform Development31:30Reaching Out to Plugin Vendors for Freeze Issues33:10Build Script Assistance from JetBrains Team33:31Tools and Experience for Freeze Analysis34:00Claude Skill for Analyzing Thread Dumps34:30Using the Claude Skill with Thread Dumps35:30Sharing the Claude Skill37:00Analyzing Thread Dumps Independently37:32Sharing Specialized Skills38:01Learning from Skill Files38:32Support Resources for Plugin Developers39:31Handling State Changes Between Read Actions41:00Eventually Consistent Approaches44:32Bridging Blocking and Suspending Code45:30Compute Detached as Last Resort47:01Automatic Notifications for Freeze Reports48:01Restart Behavior for Non-Blocking Read Actions49:32Limited Offer for Freeze Investigation51:00Available Assistance Offers52:02
In a Nutshell

UI freezes in JetBrains IDEs occur when long-running read actions or EDT operations block the write lock needed for UI updates. The fix requires using non-blocking read actions (`readAction.nonBlocking()`), splitting work into small cancellable chunks with `ProgressManager.checkCanceled()` checks, and ensuring background threads don't hold read locks during expensive computations. A long non-cancellable read action freezes the entire IDE.

AI-Generated Notes

These notes were generated by AI and may contain inaccuracies.

Patrick introduces Yuri from the platform team to discuss UI freezes in the JetBrains platform, particularly in plugins. The discussion covers freezes that occur even on high-end hardware like beefy MacBooks or PCs, where the UI becomes unresponsive to mouse and keyboard events for brief but annoying periods.

The core issue is the event dispatch thread (UI thread) becoming frozen while performing expensive operations. A common example shown in their internal system called Den demonstrates networking code being executed directly on the dispatch thread, which blocks event processing entirely.

Please never ever ever ever go internet from dispatch thread

The real problem is not that plugins attempt network operations, but that they execute them immediately on the UI thread, blocking everything. The UI thread handles all events and the event queue, so when it performs expensive work like network calls, it cannot dispatch events, repaint, or respond to user input.

The straightforward solution for dispatch thread issues is moving such code to background threads using threads, coroutines, callbacks, futures, or asynchronous frameworks. Many developers already use background threads for project analysis, code loading, reading, and processing.

Newer freeze reports present cryptic stack traces that are difficult to understand and are not obviously related to the event dispatch thread. These freezes don't show the cause directly, requiring deeper analysis.

Sign in to read the full notes

Get access to AI-generated notes, topic timestamps, and more.