GitHub Copilot 0.14.0 is causing a freeze in the Eclipse UI (unresponsive) due to a deadlock

[jchamlin]

Summary

Copilot invokes code-mining refresh synchronously from a document-change listener, which typical editor features do not do on every keystroke. This eventually leads to a deadlock, and the UI freezes. The only option is to force close Eclipse and reopen.

Feedback source

None

GitHub Copilot plugin version

0.14.0

Eclipse IDE and version

MyEclipse 2025.2 (based on Eclipse Platform 4.36, Eclipse IDE 2025-06 release)

Platform

Microsoft Windows NT 10.0.26200.0 x64
(Windows 11 x86_64)

Steps to reproduce

Install Copilot. Turn on Code Minings as required by Copilot for inline completions. You can turn off any visible display of the Code Minings to work around the screen flickering reported in #87.

Open any Java file and start typing. A larger file seems to trigger it more quickly. Eventually the UI will freeze. I'm seeing freezes about once every 15 minutes.

Logs (optional)

When frozen, jstack reports this (detailed stack trace attached)

Found one Java-level deadlock:
"main":
waiting to lock monitor 0x000001afd4248890 (object 0x0000000097342098, a java.util.concurrent.CopyOnWriteArraySet),
which is held by "ForkJoinPool.commonPool-worker-79"

"ForkJoinPool.commonPool-worker-79":
waiting to lock monitor 0x000001afda8502c0 (object 0x00000000956ef038, a java.lang.Object),
which is held by "main"

jstack-myeclipse-freeze.txt

Expected behavior

Eclipse doesn't freeze.

Actual behavior

Eclipse freezes. It's in a deadlock. The only option is to force close and restart.

Additional information

The root cause of the problem is that Copilot invokes code-mining refresh synchronously from a document-change listener, which typical editor features do not do on every keystroke.

I chatted with ChatGPT about the problem and it has some ideas on how you might be able to prevent this deadlock (see attached PDF). Here are the highlights from that conversation:

Deadlock summary

A reproducible UI deadlock occurs during typing when GitHub Copilot triggers a code-mining refresh from the UI thread inside a document change event.

The UI thread holds the editor document monitor (SynchronizableDocument) while invoking SourceViewer.updateCodeMinings(), which enters LSP4E (InlayHintProvider → LanguageServiceAccessor.getLSWrappers()) and attempts to lock the language-server wrapper set.

At the same time, an LSP4E worker thread holds the language-server wrapper set lock and attempts to determine document content types, which reads from the editor document and blocks on the document monitor.

This results in a classic lock-ordering inversion between the UI thread and an LSP4E worker thread, causing the Eclipse UI to freeze indefinitely.

Can Copilot authors fix it without platform changes?

Very possibly, yes.

Even if the deadlock manifests inside platform/LSP4E, Copilot can often avoid it by changing when/how it calls into that API:

• Don’t call updateCodeMinings() synchronously on the UI thread during a document replace.
• Defer it with an async (Display.asyncExec) so it runs after the document change completes and locks are released.
• Or schedule it (job/debounce) so it doesn’t run inside the keystroke event at all.
• Don’t invoke code mining refresh on every keystroke (debounce/throttle).
• Call a narrower API (if one exists) that doesn’t transitively force LSP4E language-server discovery / content-type sniffing.
• If Copilot must use code mining as the rendering mechanism, it can still avoid the deadlock by ensuring its refresh happens in a window where it’s not holding the document monitor.

So it’s not true that “Copilot can’t do anything.” They can almost certainly mitigate or eliminate this deadlock just by changing call timing.

Chat with ChatGPT - MyEclipse Copilot Freeze.pdf

[jchamlin]

Any update on this? I'm seeing it lock up just about every 5 minutes or so now. It has made Copilot unusable. I tried turning off completions, but it still hung, so I've had to remove the plugin from my installation.