{"id":5355,"date":"2025-11-24T11:29:01","date_gmt":"2025-11-24T11:29:01","guid":{"rendered":"http:\/\/codeguilds.com\/?p=5355"},"modified":"2025-11-24T11:29:01","modified_gmt":"2025-11-24T11:29:01","slug":"the-road-to-responsive-intellij-based-ides","status":"publish","type":"post","link":"https:\/\/codeguilds.com\/?p=5355","title":{"rendered":"The Road to Responsive IntelliJ-Based IDEs"},"content":{"rendered":"

JetBrains, a leading developer of intelligent programming tools, has unveiled significant progress in its multi-year effort to enhance the responsiveness of its IntelliJ-based Integrated Development Environments (IDEs). This ambitious project, initiated to address long-standing user complaints regarding UI performance, tackles deep-seated architectural constraints within the 25-year-old IntelliJ Platform, aiming to drastically reduce UI freezes and improve the overall user experience. The latest advancements include the development of new tools and APIs that strategically shift performance-sensitive operations away from the crucial UI thread, resulting in a substantial reduction in the time the UI thread holds the write lock\u2014by approximately one-third compared to previous versions.<\/p>\n

Understanding the Core Challenge: The Legacy of a 25-Year-Old Platform<\/strong><\/p>\n

\"The<\/figure>\n

The IntelliJ Platform, a cornerstone of popular IDEs like IntelliJ IDEA, PyCharm, and WebStorm, is a sophisticated, multithreaded framework. At its heart lies a single read-write (RW) lock, which governs access to critical data structures such as syntax trees (PSI), the text view of files (the Document subsystem), and the operating system’s file system representation (the Virtual File System, or VFS). Operations are strictly categorized into read actions and write actions. While multiple read actions can execute concurrently, only one write action can exist at any given moment, and read actions cannot run simultaneously with a write action. This fundamental design, while ensuring data consistency, presents a significant challenge for UI responsiveness.<\/p>\n

As a UI application, IntelliJ-based IDEs rely on Java AWT’s single UI thread, known as the Event Dispatch Thread (EDT). The EDT is solely responsible for processing user input, rendering the user interface, and executing certain business logic. The responsiveness of an application is directly tied to the EDT’s ability to quickly handle these tasks. When the EDT is blocked, the UI freezes, leading to a frustrating user experience characterized by perceived lag and unresponsiveness.<\/p>\n

The primary culprits behind these freezes are lengthy write actions, such as re-parsing syntax trees or updating VFS views, which are inherently resource-intensive. A less obvious but equally impactful source of freezes is the waiting period to acquire the write lock. If even a single read action is uncooperative or prolonged, the EDT\u2014and consequently the entire UI\u2014can stall while waiting for all active read actions to complete before a write action can proceed. This intricate entanglement of UI responsibilities and core data model access on a single thread was identified as the "deadly entanglement," prompting the critical engineering goal: to move write actions off the UI thread.<\/p>\n

\"The<\/figure>\n

A Multi-Year Engineering Odyssey: A Detailed Chronology of the Responsiveness Initiative<\/strong><\/p>\n

The journey towards a more responsive IntelliJ Platform has been a protracted and multi-faceted engineering endeavor, spanning several years and involving numerous key contributors.<\/p>\n

    \n
  • \n

    Phase 1: Initial Forays and the Birth of Write-Intent (2019-2020)<\/strong>
    \nThe initial push to support background write actions commenced in 2019. This foundational phase was spearheaded by Valentin Fondaratov, Andrew Kozlov, and Peter Gromov. A significant hurdle was the long-standing assumption that code executing on the EDT could safely and directly access IntelliJ Platform models. With the introduction of background write actions, this implicit safety guarantee was removed, necessitating explicit coordination for UI code accessing the model.
    \nA particular challenge arose from the fact that code on the EDT could historically initiate a write action immediately, a privilege not extended to ordinary explicit read actions. To bridge this gap while preserving compatibility, the concept of "write-intent" was introduced. Write-intent is a unique lock state that permits parallel read actions but can only be held by one thread at a time. Crucially, it can be atomically upgraded to a full write action, making it an ideal mechanism for EDT code that might need to transition into a write action without immediately blocking the UI. Despite these innovative steps, the sheer scale of the required changes, particularly concerning UI components like the editor which heavily relied on direct model access from the EDT, led to the project being temporarily paused in 2020.<\/p>\n

    \"The<\/figure>\n<\/li>\n
  • \n

    Phase 2: The Grand Refactoring and Novel Lock Mechanisms (2022-2024)<\/strong>
    \nThe project, though paused, was never abandoned. It was reignited in 2022 under the leadership of Lev Serebryakov and Daniil Ovchinnikov. This stage marked a comprehensive refactoring of the IntelliJ Platform, meticulously surfacing and addressing implicit assumptions about locking in UI-driven code paths. This effort systematically reduced the platform’s reliance on these implicit locking behaviors, paving the way for more explicit and controlled model access.
    \nA pivotal development during this period was the collaboration with the JetBrains Research team. The existing lock implementation, designed with the assumption that write actions would only run on the EDT, proved unsuitable for background execution. This collaboration led to the creation of a novel, cancelable lock mechanism, which now underpins the platform’s concurrency model. This advanced lock, detailed in a research paper (arxiv.org\/pdf\/2111.12682), was instrumental in enabling safe and efficient background write operations. This intensive refactoring and lock redesign phase concluded towards the end of 2024.<\/p>\n<\/li>\n

  • \n

    Phase 3: Conquering Modality and Incremental Migration (2025)<\/strong>
    \nBy early 2025, Konstantin Nisht assumed leadership of this critical segment of the project. The platform was nearing readiness for its first background write actions, but a major obstacle remained: modality. In the context of IntelliJ IDEs, modal dialogs\u2014such as the "Settings" dialog\u2014are designed to block user interaction with other parts of the UI until they are dismissed. Historically, modality also impacted the data model, preventing unrelated write actions from commencing while a modal dialog was active, largely managed by the EDT scheduler.
    \nBackground write actions, by their nature, did not automatically conform to this established modal model. A naive attempt to run a background write action while a modal dialog held write-intent on the EDT could lead to deadlocks. To reconcile these conflicting requirements, JetBrains introduced a sophisticated modality-aware locking strategy. This strategy effectively segregates operations inside a modal dialog from those outside it, thereby preserving the critical guarantees that modal dialogs rely upon while simultaneously allowing background write actions to execute without interference. This solution also accounted for nested modal computations, reflecting the complexities of real-world user workflows. With this mechanism in place, the team successfully executed their first write actions in the background.<\/p>\n<\/li>\n<\/ul>\n

    Moving Work Without Breaking Plugins: The Compatibility Conundrum<\/strong><\/p>\n

    \"The<\/figure>\n

    The initial background write actions, primarily within the Workspace Model for cache invalidation, were relatively straightforward. However, moving more substantial operations, like VFS refresh, presented a formidable challenge. VFS refresh, which synchronizes file modification events from the operating system with the IDE’s internal data structures, traditionally runs as a write action and triggers numerous listeners\u2014plugin code reacting to file system changes. For years, a vast amount of this listener code assumed execution on the EDT, with many directly interacting with the UI. Altering this execution model risked breaking a significant portion of the existing plugin ecosystem, much of which is outside JetBrains’ direct control.<\/p>\n

    The solution involved a pragmatic approach: keeping the core VFS refresh write action in the background but selectively handing specific listener tasks back to the EDT when compatibility dictated. Java Swing’s invokeAndWait(...)<\/code> method provided a synchronous handoff mechanism for this purpose. However, this seemingly simple solution harbored a potential deadlock: if the background write action attempted a synchronous handoff to the EDT while the EDT was itself blocked, the IDE would freeze.<\/p>\n

    To circumvent this, JetBrains developed an internal compatibility mechanism that allows carefully chosen UI events to continue processing even during these blocking waits. This incremental migration strategy proved crucial, enabling the team to move expensive write operations off the EDT while maintaining compatibility for legacy listeners. Following VFS refresh, the document commit process\u2014responsible for rebuilding PSI from documents\u2014was similarly migrated, benefiting from the robust write-action machinery already established. This innovative approach ensured that performance gains could be realized without disrupting the extensive and vital plugin ecosystem.<\/p>\n

    \"The<\/figure>\n

    Strategic Decoupling: Addressing Lock Contention on the EDT<\/strong><\/p>\n

    While background write actions significantly reduce the time the EDT spends running<\/em> write actions, they do not automatically eliminate the time it spends waiting<\/em> for locks. Even with write actions in the background, the EDT might still need to acquire read or write-intent access, and if a background write action is running or waiting, these requests can still cause UI freezes. This led to the second major thrust of the project: minimizing lock acquisition on the EDT.<\/p>\n

    The editor, a central component responsible for rendering content based on models like caret position, foldings, and document text, was a particularly problematic area. Document modifications are protected by the RW lock, yet the editor frequently requires access to this data on the EDT, even in paint paths. This meant read actions were pervasive throughout the editor’s rendering logic, potentially demanding read access at precisely the moments when UI responsiveness was paramount.<\/p>\n

    \"The<\/figure>\n

    A pragmatic trade-off was implemented: some lock requirements for editor-related EDT paths were relaxed, while certain document-related writes remained on the EDT to preserve consistency. This made editor painting less dependent on immediate lock acquisition, though the complete migration of all document modification to the background remains a future goal.<\/p>\n

    Another source of EDT lock pressure came from asynchronous computations. To maintain compatibility, many such computations inadvertently became coupled to write-intent acquisition, leading to unpredictable UI freezes. The key insight here was that for asynchronously scheduled UI work, the exact start time is often not critical. By modifying the platform’s UI scheduling, computations could be delayed until write-intent access became available, significantly reducing EDT blocking.<\/p>\n

    Quantifiable Improvements and User Impact<\/strong><\/p>\n

    \"The<\/figure>\n

    The complex architectural changes have yielded tangible results, affirming the efficacy of this multi-year investment. JetBrains tracks the time the EDT spends executing write actions as a key performance metric. Data collected one week after the release of version 2025.2 and 2025.3 demonstrates a clear improvement:<\/p>\n

      \n
    • In 2025.2, 1% of users experienced 5% of their UI time dedicated to write actions.<\/li>\n
    • In 2025.3, the same percentile of users saw this figure drop to just 3%.<\/li>\n<\/ul>\n

      Overall, the average share of UI time spent on write locks on the EDT saw a significant reduction from 1.8276% in 2025.2 to a mere 0.5298% in 2025.3. These statistics translate directly into a perceptibly more fluid and responsive user interface, reducing frustration and enhancing developer productivity. For professional developers who spend countless hours interacting with these tools, even marginal improvements in responsiveness can accumulate into substantial gains in workflow efficiency and overall satisfaction. The reduction in UI freezes means fewer interruptions, smoother navigation, and a more seamless coding experience, allowing developers to maintain their "flow state" more effectively.<\/p>\n

      Broader Implications for Developers and the Ecosystem<\/strong><\/p>\n

      \"The<\/figure>\n

      The ongoing efforts to enhance IntelliJ-based IDE responsiveness carry profound implications for both end-users and the vast ecosystem of plugin developers. For end-users, the immediate benefit is a more robust and enjoyable development environment. Reduced UI freezes translate to less waiting, smoother interactions, and a generally more pleasant user experience, which is crucial for tools relied upon daily by millions of professionals worldwide. This enhancement helps JetBrains maintain its competitive edge in a crowded market where IDE performance is a key differentiator.<\/p>\n

      For plugin developers, this project introduces a new paradigm. While JetBrains has meticulously ensured backward compatibility where possible, the underlying architectural shifts necessitate an understanding of the new threading model and APIs. The new tools and APIs are designed to help plugins decouple their logic from the EDT, encouraging developers to adopt more asynchronous and non-blocking patterns. This move, while requiring some adaptation, ultimately fosters the creation of more performant and future-proof plugins, benefiting the entire ecosystem. JetBrains’ commitment to providing granular control over thread management will empower plugin developers to build extensions that integrate more seamlessly and efficiently with the core IDE.<\/p>\n

      Future Outlook: The Road Ahead<\/strong><\/p>\n

      \"The<\/figure>\n

      Despite the significant strides made, JetBrains acknowledges that the journey towards optimal responsiveness is ongoing. Future work will concentrate on further eliminating write-intent usage from the EDT, with an ambitious long-term goal of removing locking from common interactions such as typing. This objective requires a fundamental rethinking of core platform structures like Actions, PSI (Program Structure Interface), and Documents. While challenging, the team remains confident that these deeper architectural evolutions are achievable and will lead to an even more fluid and instant user experience. This continuous commitment underscores JetBrains’ dedication to evolving its platform to meet the ever-increasing demands of modern software development.<\/p>\n

      The success of this complex project is a testament to the collaborative efforts of numerous individuals. Beyond those already mentioned, JetBrains extends its gratitude to Anna Saklakova, Dmitrii Batkovich, Vladimir Krivosheev, Moncef Slimani, Lev Serebryakov, and Nikita Koval, among others, for their direct and indirect contributions. This comprehensive endeavor, initially conceived as an internal article by Konstantin Nisht and adapted for public dissemination by Patrick Scheibe, represents a pivotal moment in the evolution of the IntelliJ Platform, promising a faster, more stable, and ultimately more productive experience for developers globally.<\/p>\n","protected":false},"excerpt":{"rendered":"

      JetBrains, a leading developer of intelligent programming tools, has unveiled significant progress in its multi-year effort to enhance the responsiveness of its IntelliJ-based Integrated Development Environments (IDEs). This ambitious project, initiated to address long-standing user complaints regarding UI performance, tackles deep-seated architectural constraints within the 25-year-old IntelliJ Platform, aiming to drastically reduce UI freezes and …<\/p>\n","protected":false},"author":27,"featured_media":5354,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[293,5,4,294,292,3,291,290],"newstopic":[],"class_list":["post-5355","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-software-engineering","tag-based","tag-development","tag-engineering","tag-ides","tag-intellij","tag-programming","tag-responsive","tag-road"],"_links":{"self":[{"href":"https:\/\/codeguilds.com\/index.php?rest_route=\/wp\/v2\/posts\/5355","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/codeguilds.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/codeguilds.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/codeguilds.com\/index.php?rest_route=\/wp\/v2\/users\/27"}],"replies":[{"embeddable":true,"href":"https:\/\/codeguilds.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=5355"}],"version-history":[{"count":0,"href":"https:\/\/codeguilds.com\/index.php?rest_route=\/wp\/v2\/posts\/5355\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/codeguilds.com\/index.php?rest_route=\/wp\/v2\/media\/5354"}],"wp:attachment":[{"href":"https:\/\/codeguilds.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=5355"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/codeguilds.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=5355"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/codeguilds.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=5355"},{"taxonomy":"newstopic","embeddable":true,"href":"https:\/\/codeguilds.com\/index.php?rest_route=%2Fwp%2Fv2%2Fnewstopic&post=5355"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}