Community
Participate
Working Groups
SDK 3.6 M6 - I had to reload my RTC Jazz workspace (~800 plugins) - for over 30 minutes the workspace was busy with 'Updating plugin dependencies' - Before I worked with Eclipse 3.6 M4 and haven't see any problems like this - looking at the threads running with JConsole, there were many jobs started 'Update classpath'. Each of them took 1/2 minute to finish Looking at the stack traces, I often found active the thread running org.eclipse.jdt.internal.compiler.util.ManifestAnalyzer.analyzeManifestContents(ManifestAnalyzer.java:48) e.g. org.eclipse.jdt.internal.compiler.util.ManifestAnalyzer.analyzeManifestContents(ManifestAnalyzer.java:48) org.eclipse.jdt.internal.core.ClasspathEntry.getCalledFileNames(ClasspathEntry.java:957) org.eclipse.jdt.internal.core.ClasspathEntry.resolvedChainedLibraries(ClasspathEntry.java:920) org.eclipse.jdt.internal.core.ClasspathEntry.resolvedChainedLibraries(ClasspathEntry.java:907) org.eclipse.jdt.internal.core.ClasspathEntry.resolvedChainedLibraries(ClasspathEntry.java:1440) org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2671) org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2777) org.eclipse.jdt.internal.core.ClasspathChange.generateDelta(ClasspathChange.java:218) org.eclipse.jdt.internal.core.DeltaProcessor.resourceChanged(DeltaProcessor.java:1916) org.eclipse.jdt.internal.core.DeltaProcessingState.resourceChanged(DeltaProcessingState.java:470) org.eclipse.core.internal.events.NotificationManager$2.run(NotificationManager.java:291) org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:285)
Alls often seen when using JConsole to see where the active threads are working: org.eclipse.jdt.internal.compiler.util.ManifestAnalyzer.analyzeManifestContents(ManifestAnalyzer.java:48) org.eclipse.jdt.internal.core.ClasspathEntry.getCalledFileNames(ClasspathEntry.java:957) org.eclipse.jdt.internal.core.ClasspathEntry.resolvedChainedLibraries(ClasspathEntry.java:920) org.eclipse.jdt.internal.core.ClasspathEntry.resolvedChainedLibraries(ClasspathEntry.java:907) org.eclipse.jdt.internal.core.ClasspathEntry.resolvedChainedLibraries(ClasspathEntry.java:1440) org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2671) org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2777) org.eclipse.jdt.internal.core.ClasspathChange.generateDelta(ClasspathChange.java:218) org.eclipse.jdt.internal.core.DeltaProcessor.resourceChanged(DeltaProcessor.java:1916) org.eclipse.jdt.internal.core.DeltaProcessingState.resourceChanged(DeltaProcessingState.java:470) org.eclipse.core.internal.events.NotificationManager$2.run(NotificationManager.java:291) org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:285)
The jobs are originating from PDE/UI component. However, CC'ing Olivier, since the time factor seems to be coming from JDT. Note that PDE is intending on coalescing the update jobs - but I don't think it will reduce the amount of work being done (bug 305242).
Jay, please contact Martin to get a reproducable test case. This might be a performance regression. I just don't see why this would be that slow.
(In reply to comment #3) > Jay, please contact Martin to get a reproducable test case. This might be a > performance regression. I just don't see why this would be that slow. One of the reasons I could think of is the change to the method org.eclipse.jdt.internal.core.JavaModelManager.getNonChainingJarsCache() as part of fix to bug 305122. Earlier (i.e. before the fix to bug 305122), the non-chaining cache was virtually used only between a full-save (or shut-down) and start-up. Once the cache is reset (during classpath re-computation etc.) it never gets populated again before a full-save is made. When the workspace is saved (or shut-down), all the classpath entries in all projects are iterated through and the list of jars that have no references to other jars (via MANIFEST) is collected and persisted. And so, when the workspace is reloaded, the cache is available and the over-head is avoided. After the fix to the aforementioned bug, the cache is not recomputed during shut-down, even if there is one entry in the cache. Since the full cache was not computed during last shut-down, the classpath resolution has to look through each JAR's manifest for referenced libraries. To confirm this, I have this question to Martin - do you see the shut-down taking any lesser time now when compared to 3.6M4? I will alter this code a bit and provide Martin a plug-in patch and see if it helps.
> do you see the shut-down taking any lesser time now > when compared to 3.6M4? I can't say, I didn't notice any unusual long time taken on shutdown on M4 and also for M6 everything works nicely. >I will alter this code a bit and provide Martin a plug-in patch and see if it > helps. That would be nice, but note that I don't intend to crash my workspace again and reload. So don't expect me to validate the fix. It would be good to measure this out with a profiler on a very large workspace.
(In reply to comment #5) > That would be nice, but note that I don't intend to crash my workspace again > and reload. So don't expect me to validate the fix. It would be good to measure > this out with a profiler on a very large workspace. Ah, I was hoping that you would be able to help me with that. Perhaps can you provide me the exact steps that lead to this situation? For e.g. you mentioned that your workspace crashed before you noticed this problem. Could you confirm that when you closed the workspace properly and reloaded again, things were alright?
Jay, Could you please try to profile this code to make sure we don't have any bottleneck that could easily be fixed? Martin, Could you please provide a big workspace to Jay so that he can work on data that reflects the problem? Thanks.
I don't think any crash played a role here. I simply repopulated my workspace: deleting all plugins and loading all plugins and features again from source control. Auto build was off. After loading all projects, 'Updating plugin dependencies' was using 1/2 hour to complete. After that I closed the workspace and restarted. Restarting was fine, didn't observe any slow down compared to other restarts.
Jay, do you have anybody working on Jazz near you? I assume loading all projects in the Eclipse SDK should be big enough to make good measurements.
I'll try to profile it.
I am waiting for data from Martin.
The decoding of the manifest itself is fast. I will try to load many projects to see if I can see anything obvious.
It looks like that most of the time is spent inside the refreshing of external resources. I'll try to debug what external resources are refreshed. I also noticed that the label decoration "Java build path indicator" is triggering classpath resolution during the check out of projects.
Jay, Could you please investigate using debug statements to see what is done during the refresh of external resources? My machine just doesn't scale to profile big test cases like this one required.
(In reply to comment #14) > Jay, > > Could you please investigate using debug statements to see what is done during > the refresh of external resources? My machine just doesn't scale to profile big > test cases like this one required. It's true we did have issues with refreshing external folders, which is fixed in 302295. The issue was that external folders were refreshed once for each project in the workspace. Perhaps that's what you are seeing? Martin, could you please try one of the recent builds and see if you still have this problem?
Chatted with Martin: he hasn't seen this bug with latest builds. *** This bug has been marked as a duplicate of bug 302295 ***
See this bug all the time using latest Neon. Also "Updating plug-in dependencies" does not only take forever, the IDE is also not responsive anymore.
I think this is not a duplicate, since using Eclipse's suggestions on package import/ Bundle import (Plugin-Development) causes this error too.
Everything that affects the classpath can (for me will) cause this problem.
Running 4.6 (Neon) and have the same bug again! As soon as Eclipse figures it needs to go into "Updating plugin dependencies" it's coffee time (5-15(!) minues) :-( No wonder is this beast slowly dying...
(In reply to Michael Moser from comment #20) > Running 4.6 (Neon) and have the same bug again! As soon as Eclipse figures > it needs to go into "Updating plugin dependencies" it's coffee time (5-15(!) > minues) :-( > > No wonder is this beast slowly dying... Please file a new bug report with steps to reproduce or with a test case.
