Xtext can cause serious lock/blocking in UI thread while debugging

Double clicked on a breakpoint and Eclipse became unresponsive.

The captured stack (with jstack) showed this:

"main" #1 prio=6 os_prio=31 cpu=24537.68ms elapsed=196.26s tid=0x00007fd14d80ce00 nid=0x103 in Object.wait()  [0x00007ff7b42d4000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
	at java.lang.Object.wait(java.base@17.0.5/Native Method)
	- waiting on <no object reference available>
	at org.eclipse.jdt.internal.core.search.processing.JobManager.performConcurrentJob(JobManager.java:351)
	- locked <0x00000000a0682398> (a org.eclipse.jdt.internal.core.search.indexing.IndexManager)
	at org.eclipse.jdt.internal.core.search.BasicSearchEngine.searchAllTypeNames(BasicSearchEngine.java:1923)
	at org.eclipse.jdt.internal.core.search.BasicSearchEngine.searchAllTypeNames(BasicSearchEngine.java:1751)
	at org.eclipse.jdt.core.search.SearchEngine.searchAllTypeNames(SearchEngine.java:1202)
	at org.eclipse.xtext.common.types.shared.jdt38.OriginalEditorSelector.findTypesBySimpleName(OriginalEditorSelector.java:244)
	at org.eclipse.xtext.common.types.shared.jdt38.OriginalEditorSelector.findJavaTypeForSimpleFileName(OriginalEditorSelector.java:192)
	at org.eclipse.xtext.common.types.shared.jdt38.OriginalEditorSelector.findXbaseEditor(OriginalEditorSelector.java:119)
	at org.eclipse.xtext.common.types.shared.jdt38.OriginalEditorSelector.overrideDefaultEditor(OriginalEditorSelector.java:104)
	at org.eclipse.ui.ide.IDE.overrideDefaultEditorAssociation(IDE.java:870)
	at org.eclipse.ui.ide.IDE.getEditorDescriptor(IDE.java:1020)
	at org.eclipse.ui.ide.IDE.getEditorDescriptor(IDE.java:968)
	at org.eclipse.jdt.internal.debug.ui.JDIModelPresentation.getEditorId(JDIModelPresentation.java:1238)
	at org.eclipse.debug.internal.ui.LazyModelPresentation.getEditorId(LazyModelPresentation.java:250)
	at org.eclipse.debug.internal.ui.DelegatingModelPresentation.getEditorId(DelegatingModelPresentation.java:169)
	at org.eclipse.debug.internal.ui.actions.breakpoints.OpenBreakpointMarkerAction.run(OpenBreakpointMarkerAction.java:74)
	at org.eclipse.debug.internal.ui.views.variables.VariablesView.doubleClick(VariablesView.java:1280)
	at org.eclipse.jface.viewers.StructuredViewer$1.run(StructuredViewer.java:781)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
	at org.eclipse.ui.internal.JFaceUtil$$Lambda$166/0x00000008011c7ca0.run(Unknown Source)
	at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:174)
	at org.eclipse.jface.viewers.StructuredViewer.fireDoubleClick(StructuredViewer.java:778)
	at org.eclipse.jface.viewers.AbstractTreeViewer.handleDoubleSelect(AbstractTreeViewer.java:1570)
	at org.eclipse.jface.viewers.StructuredViewer$4.widgetDefaultSelected(StructuredViewer.java:1216)
	at org.eclipse.jface.util.OpenStrategy.fireDefaultSelectionEvent(OpenStrategy.java:272)
	at org.eclipse.jface.util.OpenStrategy$1.handleEvent(OpenStrategy.java:329)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89)
	at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4646)

Start with the captured call path from VariablesView.doubleClick through OpenBreakpointMarkerAction and JDIModelPresentation.getEditorId into OriginalEditorSelector. Inspect the search in OriginalEditorSelector.findTypesBySimpleName and the surrounding Eclipse JDT calls to understand the UI-thread blocking. Done means opening a breakpoint no longer leaves the Eclipse UI unresponsive.