Comment 1 Lars Vogel 2019-06-18 08:30:20 EDT

Mickael, does the stack give you a hint what can be wrong here?

Comment 2 Lars Vogel 2019-06-18 08:34:31 EDT

The UI shows "Updating PDE dependencies", so this might also be PDE related, adding Julian.

Comment 3 Lars Vogel 2019-06-18 08:59:01 EDT

Here is another stack trace this time with Egit involved, adding Thomas.

Stack Trace
	at org.eclipse.jdt.internal.compiler.classfmt.ClassFileStruct.utf8At(ClassFileStruct.java:63)
	at org.eclipse.jdt.internal.compiler.classfmt.ModuleInfo.readModuleAttribute(ModuleInfo.java:130)
	at org.eclipse.jdt.internal.compiler.classfmt.ModuleInfo.createModule(ModuleInfo.java:113)
	at org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.<init>(ClassFileReader.java:440)
	at org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.<init>(ClassFileReader.java:180)
	at org.eclipse.jdt.internal.compiler.util.JrtFileSystem.getClassfile(JRTUtil.java:498)
	at org.eclipse.jdt.internal.compiler.util.JRTUtil.getClassfile(JRTUtil.java:174)
	at org.eclipse.jdt.internal.core.JavaProject$ModuleLookup.getModule(JavaProject.java:877)
	at org.eclipse.jdt.internal.core.JavaProject$ModuleLookup.addTransitive(JavaProject.java:865)
	at org.eclipse.jdt.internal.core.JavaProject.filterLimitedModules(JavaProject.java:840)
	at org.eclipse.jdt.internal.core.JavaProject.computePackageFragmentRoots(JavaProject.java:741)
	at org.eclipse.jdt.internal.core.JavaProject.computePackageFragmentRoots(JavaProject.java:1046)
	at org.eclipse.jdt.internal.core.JavaProject.computePackageFragmentRoots(JavaProject.java:991)
	at org.eclipse.jdt.internal.core.JavaProject.computePackageFragmentRoots(JavaProject.java:968)
	at org.eclipse.jdt.internal.core.JavaProject.findPackageFragmentRoots(JavaProject.java:1609)
	at org.eclipse.jdt.internal.ui.packageview.ClassPathContainer.getPackageFragmentRoots(ClassPathContainer.java:183)
	at org.eclipse.jdt.ui.JavaElementComparator.getPackageFragmentRoot(JavaElementComparator.java:298)
	at org.eclipse.jdt.ui.JavaElementComparator.compare(JavaElementComparator.java:208)
	at org.eclipse.jdt.ui.JavaElementSorter.compare(JavaElementSorter.java:72)
	at org.eclipse.ui.navigator.CommonViewerSorter.compare(CommonViewerSorter.java:140)
	at org.eclipse.jface.viewers.TreePathViewerSorter.lambda$0(TreePathViewerSorter.java:105)
	at org.eclipse.jface.viewers.TreePathViewerSorter$$Lambda$471/0x000000010092b440.compare(Unknown Source)
	at java.base@11.0.2/java.util.TimSort.binarySort(TimSort.java:296)
	at java.base@11.0.2/java.util.TimSort.sort(TimSort.java:221)
	at java.base@11.0.2/java.util.Arrays.sort(Arrays.java:1441)
	at org.eclipse.jface.viewers.TreePathViewerSorter.sort(TreePathViewerSorter.java:105)
	at org.eclipse.jface.viewers.AbstractTreeViewer.getSortedChildren(AbstractTreeViewer.java:639)
	at org.eclipse.jface.viewers.AbstractTreeViewer.updateChildren(AbstractTreeViewer.java:2657)
	at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefreshStruct(AbstractTreeViewer.java:1947)
	at org.eclipse.jface.viewers.TreeViewer.internalRefreshStruct(TreeViewer.java:677)
	at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefreshStruct(AbstractTreeViewer.java:1953)
	at org.eclipse.jface.viewers.TreeViewer.internalRefreshStruct(TreeViewer.java:677)
	at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1923)
	at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1880)
	at org.eclipse.ui.navigator.CommonViewer.internalRefresh(CommonViewer.java:532)
	at org.eclipse.jface.viewers.StructuredViewer.lambda$3(StructuredViewer.java:1475)
	at org.eclipse.jface.viewers.StructuredViewer$$Lambda$447/0x0000000100907440.run(Unknown Source)
	at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1391)
	at org.eclipse.jface.viewers.TreeViewer.preservingSelection(TreeViewer.java:363)
	at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1352)
	at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1475)
	at org.eclipse.jface.viewers.ColumnViewer.refresh(ColumnViewer.java:538)
	at org.eclipse.ui.navigator.CommonViewer.refresh(CommonViewer.java:352)
	at org.eclipse.ui.navigator.CommonViewer.refresh(CommonViewer.java:495)
	at org.eclipse.ui.internal.navigator.resources.workbench.ResourceExtensionContentProvider.lambda$2(ResourceExtensionContentProvider.java:268)
	at org.eclipse.ui.internal.navigator.resources.workbench.ResourceExtensionContentProvider$$Lambda$2083/0x0000000101a21840.run(Unknown Source)
	at org.eclipse.ui.internal.navigator.resources.workbench.ResourceExtensionContentProvider.runUpdates(ResourceExtensionContentProvider.java:277)
	at org.eclipse.ui.internal.navigator.resources.workbench.ResourceExtensionContentProvider.lambda$0(ResourceExtensionContentProvider.java:117)
	at org.eclipse.ui.internal.navigator.resources.workbench.ResourceExtensionContentProvider$$Lambda$2085/0x0000000101a58c40.run(Unknown Source)
	at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:185)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:5126)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4679)
	at org.eclipse.jface.window.Window.runEventLoop(Window.java:823)
	at org.eclipse.jface.window.Window.open(Window.java:799)
	at org.eclipse.egit.ui.internal.staging.StagingView.commit(StagingView.java:4226)
	at org.eclipse.egit.ui.internal.staging.StagingView.access$28(StagingView.java:4217)
	at org.eclipse.egit.ui.internal.staging.StagingView$22.widgetSelected(StagingView.java:1166)
	at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:252)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89)
	at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5887)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1400)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:5151)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4676)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1159)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1048)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155)
	at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:635)
	at org.eclipse.ui.internal.Workbench$$Lambda$184/0x0000000100324440.run(Unknown Source)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:559)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:155)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:137)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:107)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255)
	at java.base@11.0.2/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base@11.0.2/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base@11.0.2/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base@11.0.2/java.lang.reflect.Method.invoke(Method.java:566)
	at app//org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:660)
	at app//org.eclipse.equinox.launcher.Main.basicRun(Main.java:597)
	at app//org.eclipse.equinox.launcher.Main.run(Main.java:1468)
	at app//org.eclipse.equinox.launcher.Main.main(Main.java:1441)

Comment 4 Thomas Wolf 2019-06-18 09:06:48 EDT

(In reply to Lars Vogel from comment #3)
> Here is another stack trace this time with Egit involved, adding Thomas.

EGit involvement is a red herring. StagingView just wants to open a MessageDialog, but in doing so Display.runAsyncMessages runs this lambda inside ResourceExtensionContentProvider trying to refresh some viewer.

Comment 5 Lars Vogel 2019-06-18 09:18:14 EDT

(In reply to Thomas Wolf from comment #4)
> (In reply to Lars Vogel from comment #3)
> > Here is another stack trace this time with Egit involved, adding Thomas.
> 
> EGit involvement is a red herring. StagingView just wants to open a
> MessageDialog, but in doing so Display.runAsyncMessages runs this lambda
> inside ResourceExtensionContentProvider trying to refresh some viewer.

Why does EGit wants to open a MessageDialog, if I change bundle versions via the MANIFEST.MF editor?

P.S. red herring was a new phrase to me. Cool phrase, I need to find places to use it. :-)

Comment 6 Lars Vogel 2019-06-18 09:27:12 EDT

(In reply to Lars Vogel from comment #5)
> Why does EGit wants to open a MessageDialog, if I change bundle versions via
> the MANIFEST.MF editor?

If this helps: I seem to have a bunch of EGit notications dialogs stacked. Every time I click on the "Progress" icon, a "Push result" dialog opens. If I click again, another opens up. The last days I push a lot of smaller patches.

I did not care about them, as they are not blocking dialogs ;-), I just avoid clicking on this button.

Comment 7 Thomas Wolf 2019-06-18 09:30:28 EDT

Off-topic: I don't know what you did in the UI, but this dialog definitely wasn't triggered by your changing bundle versions. It also has got nothing to do with stacked push result dialogs. It's triggered when you try to commit without staged files. And yes, there's an open bug report in EGit somewhere about getting rid of this dialog and disabling the commit altogether. But that all has nothing to do with this bug report here.

Comment 8 Lars Vogel 2019-06-18 09:45:36 EDT

(In reply to Thomas Wolf from comment #7)
> Off-topic: I don't know what you did in the UI, but this dialog definitely
> wasn't triggered by your changing bundle versions. 

;-)

> It also has got nothing
> to do with stacked push result dialogs. It's triggered when you try to
> commit without staged files.

:-) Can can 100% reproduce, screen recording upcoming.

Comment 9 Lars Vogel 2019-06-18 10:02:05 EDT

(In reply to Lars Vogel from comment #8)
> :-) Can can 100% reproduce, screen recording upcoming.

Ah, EGit is reported as freeze, as I clicked on the progress bar which triggered Eclipse to try to open the EGit "Push success" dialog. The real slow guy is here the first stack trace.

Comment 10 Lars Vogel 2019-06-18 10:05:08 EDT

(In reply to Lars Vogel from comment #9)

So EGit involvement was indeed a red herring.

Comment 11 Lars Vogel 2019-06-18 10:27:43 EDT

If I close the Project Explorer the freeze is gone.

@Mickael, Project Explorer was not in the foreground (I used Package Explorer) and still blocked the UI for ~20 secs. Maybe this update can be avoided in my case?

Comment 12 Andrey Loskutov 2019-06-18 10:37:30 EDT

You don't have nested projects?  See bug 541040.
Beside this, bug 204498 seem to be related.

Comment 13 Lars Vogel 2019-06-18 10:44:02 EDT

(In reply to Andrey Loskutov from comment #12)
> You don't have nested projects?  
I do not have nested projects

Comment 14 Mickael Istria 2019-06-19 16:02:59 EDT

Do you see it in Project Explorer and/or Package Explorer? Tried both? If Project Explorer, did you see it in Flat and/or hierarchical mode? Tried both?
My first hibt would be that some pçugin.coyld «touch» resources quite often, more than usual, causing the Project Explorer to refresh too often.
Supposed I'm right, the Project Explorer might be improved, but I think it'd be better to find out where all those resource updates come from first. Tracepoibts/breakpoints on occurrences of runnables.add(...) in ResoueceExtensionContentProvider will help on that matter.

Comment 15 Lars Vogel 2019-06-20 01:28:15 EDT

(In reply to Mickael Istria from comment #14)
> Do you see it in Project Explorer and/or Package Explorer? Tried both? If
> Project Explorer, did you see it in Flat and/or hierarchical mode? Tried
> both?
> My first hibt would be that some pçugin.coyld «touch» resources quite often,
> more than usual, causing the Project Explorer to refresh too often.
> Supposed I'm right, the Project Explorer might be improved, but I think it'd
> be better to find out where all those resource updates come from first.
> Tracepoibts/breakpoints on occurrences of runnables.add(...) in
> ResoueceExtensionContentProvider will help on that matter.

I see it only if the project explorer is open. And I only use flat mode. The freeze happens even if project explorer is not visible, i.e. is behind the package explorer.

Comment 16 Andrey Loskutov 2019-08-02 10:51:28 EDT

*** Bug 549737 has been marked as a duplicate of this bug. ***

Comment 17 Markus S 2019-08-02 10:57:13 EDT

When can we expect a fix for this behavior? I'm experiencing a blocking UI for over 10 minutes multiple times a day.

Comment 18 Andrey Loskutov 2019-08-02 11:00:30 EDT

(In reply to Markus Mising name from comment #17)
> When can we expect a fix for this behavior? I'm experiencing a blocking UI
> for over 10 minutes multiple times a day.

Almost immediately, if you contribute a patch: https://wiki.eclipse.org/Platform/How_to_Contribute

Comment 19 Markus S 2019-08-02 11:01:48 EDT

Please avoid such irritating sentences in reports, it's really not encouraging.

Comment 20 Mickael Istria 2019-08-20 11:38:11 EDT

Has anyone facing this issue idenfied some action and project that makes the freeze somehow reproducible?
I think the issue isn't necessarily in the navigator per se, but could be another plugin that sends many more resource change events. If we can track the Resource events that are sent, we may be able to send less such events and/or improve navigator to ignore some of those events if they have no payload from a navigator perspective.

Comment 21 Mickael Istria 2019-08-20 12:32:13 EDT

I got it: when working on bug 530450, i removed this part of code by mistake

  	final SortedSet<IResource> resourcesToRefresh = new TreeSet<IResource>(new Comparator<IResource>() {
		private PathComparator pathComparator = new PathComparator();
		@Override
			public int compare(IResource arg0, IResource arg1) {
			return pathComparator.compare(arg0.getFullPath(), arg1.getFullPath());
		}
	});
	[...]
	Resource currentTopLevelResource = null;
	for (IResource resource : resourcesToRefresh) {
		if (resource == null) {
			// paranoia, see bug 509821
			continue;
		}
		if (currentTopLevelResource == null
				|| !currentTopLevelResource.getFullPath().isPrefixOf(resource.getFullPath())) {
			currentTopLevelResource = resource;
			runnables.add(getRefreshRunnable(resource));
		}
	}

As a result, a lot of refresh as triggered from the navigator (can be N refresh for a whole file hierarchy instead of 1).

Comment 22 Andrey Loskutov 2019-08-20 12:52:13 EDT

(In reply to Mickael Istria from comment #21)
> I got it: when working on bug 530450, i removed this part of code by mistake
> 
> As a result, a lot of refresh as triggered from the navigator (can be N
> refresh for a whole file hierarchy instead of 1).

Do you mean, that piece of code is currently *missing* and is related to this problem? Do you want to provide a patch?

Comment 23 Mickael Istria 2019-08-20 12:56:16 EDT

(In reply to Andrey Loskutov from comment #22)
> Do you mean, that piece of code is currently *missing*

Yes.

> and is related to this problem?

Yes, as it drastically reduces the number of refresh request (both stacks show that they were processing a refresh request).

> Do you want to provide a patch?

Of course, I'm on it.
My only concern is about testing: I wasn't so much able to reproduce the issue, and submitting a patch would require someone to be able to reproduce the issue easily in a test workspace (from navigator source code), apply the patch, and check it's better.

Comment 24 Eclipse Genie 2019-08-20 12:57:34 EDT

New Gerrit change created: https://git.eclipse.org/r/148002

Comment 25 Lars Vogel 2019-08-20 13:01:55 EDT

(In reply to Eclipse Genie from comment #24)
> New Gerrit change created: https://git.eclipse.org/r/148002

I can test tomorrow, I can easily reproduce this issue.

Comment 26 Lars Vogel 2019-08-21 04:23:52 EDT

(In reply to Lars Vogel from comment #25)
> (In reply to Eclipse Genie from comment #24)
> > New Gerrit change created: https://git.eclipse.org/r/148002
> 
> I can test tomorrow, I can easily reproduce this issue.

I can confirm that I don't see the reported UI freezes anymore with this patch. Without this patch I have regular > 10 seconds freezes due to the project explorer when updating a MANIFEST.MF dependency in a larger workspace. With this patch, Eclipse stays responsive.

Would IMHO be good to have that in M3. Eclipse runs again fast as a fox with this patch for me.

Comment 27 Mickael Istria 2019-08-21 04:28:00 EDT

I'd be fine having it merged for M3, but I think the process doesn't allow to just merge it.
Can you please discuss it with PMC to decide whether this can be an exception and merged soon?

Comment 28 Lars Vogel 2019-08-21 04:38:48 EDT

(In reply to Mickael Istria from comment #27)
> I'd be fine having it merged for M3, but I think the process doesn't allow
> to just merge it.
> Can you please discuss it with PMC to decide whether this can be an
> exception and merged soon?

AFAIK it is fine to merge fixes but I'm also ok if we merging it for RC1.

Comment 29 Lars Vogel 2019-08-21 04:39:32 EDT

(In reply to Lars Vogel from comment #28)
> (In reply to Mickael Istria from comment #27)
> > I'd be fine having it merged for M3, but I think the process doesn't allow
> > to just merge it.
> > Can you please discuss it with PMC to decide whether this can be an
> > exception and merged soon?
> 
> AFAIK it is fine to merge fixes but I'm also ok if we merging it for RC1.

Dani, WDYT?

Comment 30 Mickael Istria 2019-08-22 11:53:48 EDT

@Lars/Dani: do you approve inclusion of that fix for RC1?

Comment 31 Lars Vogel 2019-08-22 11:56:02 EDT

(In reply to Mickael Istria from comment #30)
> @Lars/Dani: do you approve inclusion of that fix for RC1?

+1 from project lead

Comment 32 Eclipse Genie 2019-08-22 12:04:33 EDT

Gerrit change https://git.eclipse.org/r/148002 was merged to [master].
Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=67aad8ee76c2f6bbe1a0880c13e65f507fc16de7

Comment 33 Mickael Istria 2019-08-22 12:04:46 EDT

Merged fix for RC1 with Lars review on Gerrit and approval as lead.

Comment 34 Lars Vogel 2019-08-22 12:27:00 EDT

Thanks Mickael for working on this. Eclipse became unusable for me without this this in a bigger workspace.

Comment 35 Dani Megert 2019-08-23 08:42:42 EDT

(In reply to Mickael Istria from comment #33)
> Merged fix for RC1 with Lars review on Gerrit and approval as lead.
Just for the protocol: you merged this while master was still closed. Please avoid this in the future.