Community
Participate
Working Groups
After upgrading to Eclipse 4.8 eclipse does of full build of my workspace on each start. Eclipse IDE for RCP and RAP Developers Version: Photon Release (4.8.0) Build id: 20180619-1200
This issue is quite annoying. A full build is not necessary at startup and delays the startup process by several minutes (in our case). During this time you can neither change and save files nor start your application...
That's not what I see having just JDT from 4.8. Can you provided a concrete test case?
Unfortunately not - I can only say that a full build is started when I start eclipse. But I can provide more informations if you explain what you need.
Steps to reproduce: 1. Download RCP Developer version of Eclipse: http://www.eclipse.org/downloads/packages/eclipse-ide-rcp-and-rap-developers/photonr 2. Install Eclipse Plug-in Development Environment 3.13.100.v20180611-0826 via Update Site http://download.eclipse.org/eclipse/updates/4.8 3. Import sources for all org.eclipse.pde plugins 4. Restart Eclipse You should now be able to observe that a full build is started (meaning that all plugins are cleaned and build). On my private System that takes about 35 seconds. System info: application=org.eclipse.ui.ide.workbench buildId=4.8.0.I20180611-0500 java.runtime.version=1.8.0_171-b11 os.arch=amd64 os.name=Windows 10 os.version=10.0
Michael, can you please try to collect some tracing information? Go to the Window -> Preferences -> General -> Tracing. Here "enable tracing", expand "Platform Core Resources" node and enable org.eclipse.core.resources/debug=true org.eclipse.core.resources/build/needbuildstack=true org.eclipse.core.resources/build/needbuild=true org.eclipse.core.resources/build/invoking=true org.eclipse.core.resources/build/interrupt=true Make sure you write trace in the log file, Apply and restart Eclipse. I also observe this rebuilds on my PC, with my main workspace containing most of Platform plugins in sources. Here is what I see in the trace at the beginning of the rebuild, note the line with org.eclipse.jdt.internal.ui.workingsets.DynamicSourcesWorkingSetUpdater$1(Update dynamic Java sources working sets): Auto-Build requested, needsBuild: true: | Worker-3: Processing Java changes since last activation | 2018-07-21 23:49:38.213 | org.eclipse.core.resources | /debug | org.eclipse.core.internal.utils.Policy | debug | 130 | org.eclipse.jdt.internal.core.JavaModelManager$20(Processing Java changes since last activation): Auto-Build requested, needsBuild: false state: 0 delay: 100 | | Worker-10: Building workspace | 2018-07-21 23:49:38.322 | org.eclipse.core.resources | /debug | org.eclipse.core.internal.utils.Policy | debug | 130 | org.eclipse.core.internal.events.AutoBuildJob(Building workspace): Auto-Build requested, needsBuild: false state: 4 delay: 100 | | Worker-2: Update dynamic Java sources working sets | 2018-07-21 23:49:43.055 | org.eclipse.core.resources | /debug | org.eclipse.core.internal.utils.Policy | debug | 130 | org.eclipse.jdt.internal.ui.workingsets.DynamicSourcesWorkingSetUpdater$1(Update dynamic Java sources working sets): Auto-Build requested, needsBuild: true state: 0 delay: 100 | | Worker-2: Update dynamic Java sources working sets | 2018-07-21 23:49:43.071 | org.eclipse.core.resources | /debug | org.eclipse.core.internal.utils.Policy | debug | 130 | org.eclipse.jdt.internal.ui.workingsets.DynamicSourcesWorkingSetUpdater$1(Update dynamic Java sources working sets): java.lang.RuntimeException: Build needed at org.eclipse.core.internal.events.AutoBuildJob.build(AutoBuildJob.java:80) at org.eclipse.core.internal.events.BuildManager.endTopLevel(BuildManager.java:573) at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:1514) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2302) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2316) at org.eclipse.jdt.internal.core.JavaModelManager.initializeAllContainers(JavaModelManager.java:3130) at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:2115) at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:3619) at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:3159) at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:3323) at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:2400) at org.eclipse.jdt.internal.core.JavaProject.buildStructure(JavaProject.java:475) at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:265) at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:593) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:323) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:309) at org.eclipse.jdt.internal.core.JavaElement.getChildren(JavaElement.java:264) at org.eclipse.jdt.internal.core.JavaProject.getPackageFragmentRoots(JavaProject.java:2276) at org.eclipse.jdt.internal.ui.workingsets.DynamicSourcesWorkingSetUpdater.updateElements(DynamicSourcesWorkingSetUpdater.java:198) at org.eclipse.jdt.internal.ui.workingsets.DynamicSourcesWorkingSetUpdater.updateElements(DynamicSourcesWorkingSetUpdater.java:179) at org.eclipse.jdt.internal.ui.workingsets.DynamicSourcesWorkingSetUpdater$1.run(DynamicSourcesWorkingSetUpdater.java:166) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:60) |
Hmm, if I had a Java file opened before shutdown, the stack shows that just restoring this editor requests a new build after some classpath initialization in JavaModelManager.getClasspathContainer(), th stack is similar to what we saw above. Sounds like JDT classpath resolving triggers auto-build with "Build needed" flag. .utils.Policy | debug | 130 | Auto-Build requested, needsBuild: true state: 0 delay: 100 | | main | 2018-07-22 00:13:01.352 | org.eclipse.core.resources | /debug | org.eclipse.core.internal.utils.Policy | debug | 130 | java.lang.RuntimeException: Build needed at org.eclipse.core.internal.events.AutoBuildJob.build(AutoBuildJob.java:80) at org.eclipse.core.internal.events.BuildManager.endTopLevel(BuildManager.java:573) at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:1514) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2302) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2316) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:804) at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:2123) at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:3619) at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:3159) at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:3323) at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:2400) at org.eclipse.jdt.internal.core.PackageFragmentRoot.getRawClasspathEntry(PackageFragmentRoot.java:588) at org.eclipse.jdt.internal.ui.packageview.PackageExplorerContentProvider.internalGetParent(PackageExplorerContentProvider.java:391) at org.eclipse.jdt.internal.ui.packageview.PackageExplorerContentProvider.processDelta(PackageExplorerContentProvider.java:752) at org.eclipse.jdt.internal.ui.packageview.PackageExplorerContentProvider.handleAffectedChildren(PackageExplorerContentProvider.java:833) at org.eclipse.jdt.internal.ui.packageview.PackageExplorerContentProvider.processDelta(PackageExplorerContentProvider.java:776) at org.eclipse.jdt.internal.ui.packageview.PackageExplorerContentProvider.handleAffectedChildren(PackageExplorerContentProvider.java:833) at org.eclipse.jdt.internal.ui.packageview.PackageExplorerContentProvider.processDelta(PackageExplorerContentProvider.java:776) at org.eclipse.jdt.internal.ui.packageview.PackageExplorerContentProvider.elementChanged(PackageExplorerContentProvider.java:135) at org.eclipse.jdt.internal.core.DeltaProcessor$3.run(DeltaProcessor.java:1735) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.jdt.internal.core.DeltaProcessor.notifyListeners(DeltaProcessor.java:1723) at org.eclipse.jdt.internal.core.DeltaProcessor.firePostChangeDelta(DeltaProcessor.java:1556) at org.eclipse.jdt.internal.core.DeltaProcessor.fire(DeltaProcessor.java:1532) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:774) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:799) at org.eclipse.jdt.internal.core.CompilationUnit.becomeWorkingCopy(CompilationUnit.java:96) at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider.createFileInfo(CompilationUnitDocumentProvider.java:1031) at org.eclipse.ui.editors.text.TextFileDocumentProvider.connect(TextFileDocumentProvider.java:478) at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider.connect(CompilationUnitDocumentProvider.java:1274) at org.eclipse.ui.texteditor.AbstractTextEditor.doSetInput(AbstractTextEditor.java:4164) at org.eclipse.ui.texteditor.StatusTextEditor.doSetInput(StatusTextEditor.java:257) at org.eclipse.ui.texteditor.AbstractDecoratedTextEditor.doSetInput(AbstractDecoratedTextEditor.java:1473) at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.internalDoSetInput(JavaEditor.java:2570) at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.doSetInput(JavaEditor.java:2543) at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.doSetInput(CompilationUnitEditor.java:1420) at org.eclipse.ui.texteditor.AbstractTextEditor.lambda$1(AbstractTextEditor.java:3132) at org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:2173) at org.eclipse.ui.texteditor.AbstractTextEditor.internalInit(AbstractTextEditor.java:3149) at org.eclipse.ui.texteditor.AbstractTextEditor.init(AbstractTextEditor.java:3174) at org.eclipse.ui.internal.EditorReference.initialize(EditorReference.java:362) at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.create(CompatibilityPart.java:342)
I observed this in the Xtext development workspace too. I thought this was related to how we use oomph and what happens in our oomph setup. Will try to enable tracing too
Created attachment 275078 [details] Log And Tracefiles after restart in Oomped Xtext Development Workspace
Created attachment 275079 [details] Simple Workspace with a few plugin projects logs
Created attachment 275080 [details] More Log Files Did some more restarts. depending how and what interrupts happen getting full or incremental builds
Created attachment 275081 [details] happens too with removed xtext builders
I can reproduce with a fresh workspace, containing simple Java project with a single Java file containing this code: public class Main { public static void main(String[] args) { System.out.println("Hello"); } } If this editor is opened before startup, JDT seem to trigger autobuild after / during classpath init. org.eclipse.jdt.core/debug=true org.eclipse.jdt.core/debug/javamodel/classpath=true org.eclipse.jdt.core/debug/builder=true org.eclipse.jdt.core/debug/cpresolution=true org.eclipse.jdt.core/debug/cpresolution/failure=true org.eclipse.jdt.core/debug/resolution=true org.eclipse.jdt.core/debug/javamodel/invalid_archives=true I'm looking into org.eclipse.jdt.internal.core.SetContainerOperation.executeOperation() right now. The project has no dependencies except to the JDK 1.8, and it looks like the standard JRE container restore on startup goes somehow wrong, so that on every startup the container is re-set again on project classpath. Thread[main,6,main] CPContainer SET - missbehaving container Thread[main,6,main] container path: org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.8
Not sure if I'm on the right track. SetContainerOperation seem always be executed for a project on startup, and it always triggers project.touch() which in turn sets the "hasBuildChanges" flag in WorkManager. ??? Thread [main] (Suspended (breakpoint at line 285 in WorkManager)) WorkManager.setBuild(boolean) line: 285 Workspace.endOperation(ISchedulingRule, boolean) line: 1476 Project(Resource).touch(IProgressMonitor) line: 1750 Project.touch(IProgressMonitor) line: 1318 SetContainerOperation.executeOperation() line: 117 SetContainerOperation(JavaModelOperation).run(IProgressMonitor) line: 733 Workspace.run(ICoreRunnable, ISchedulingRule, int, IProgressMonitor) line: 2289 Workspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor) line: 2316 SetContainerOperation(JavaModelOperation).runOperation(IProgressMonitor) line: 804 JavaModelManager.getClasspathContainer(IPath, IJavaProject) line: 2123 JavaCore.getClasspathContainer(IPath, IJavaProject) line: 3619 JavaProject.resolveClasspath(IClasspathEntry[], IClasspathEntry[], boolean, boolean) line: 3159 JavaProject.resolveClasspath(JavaModelManager$PerProjectInfo, boolean, boolean) line: 3323 JavaProject.getResolvedClasspath() line: 2400 PackageFragmentRoot.getRawClasspathEntry() line: 588 PackageExplorerContentProvider.internalGetParent(Object) line: 391 PackageExplorerContentProvider.processDelta(IJavaElementDelta, Collection<Runnable>) line: 752 PackageExplorerContentProvider.handleAffectedChildren(IJavaElementDelta, IJavaElement, Collection<Runnable>) line: 833 PackageExplorerContentProvider.processDelta(IJavaElementDelta, Collection<Runnable>) line: 776 PackageExplorerContentProvider.handleAffectedChildren(IJavaElementDelta, IJavaElement, Collection<Runnable>) line: 833 PackageExplorerContentProvider.processDelta(IJavaElementDelta, Collection<Runnable>) line: 776 PackageExplorerContentProvider.elementChanged(ElementChangedEvent) line: 135 DeltaProcessor$3.run() line: 1735 SafeRunner.run(ISafeRunnable) line: 42 DeltaProcessor.notifyListeners(IJavaElementDelta, int, IElementChangedListener[], int[], int) line: 1723 DeltaProcessor.firePostChangeDelta(IJavaElementDelta, IElementChangedListener[], int[], int) line: 1556 DeltaProcessor.fire(IJavaElementDelta, int) line: 1532 BecomeWorkingCopyOperation(JavaModelOperation).run(IProgressMonitor) line: 774 BecomeWorkingCopyOperation(JavaModelOperation).runOperation(IProgressMonitor) line: 799 CompilationUnit.becomeWorkingCopy(IProblemRequestor, IProgressMonitor) line: 96 CompilationUnitDocumentProvider.createFileInfo(Object) line: 1031 CompilationUnitDocumentProvider(TextFileDocumentProvider).connect(Object) line: 478 CompilationUnitDocumentProvider.connect(Object) line: 1274 CompilationUnitEditor(AbstractTextEditor).doSetInput(IEditorInput) line: 4164 CompilationUnitEditor(StatusTextEditor).doSetInput(IEditorInput) line: 257 CompilationUnitEditor(AbstractDecoratedTextEditor).doSetInput(IEditorInput) line: 1473 CompilationUnitEditor(JavaEditor).internalDoSetInput(IEditorInput) line: 2570 CompilationUnitEditor(JavaEditor).doSetInput(IEditorInput) line: 2543 CompilationUnitEditor.doSetInput(IEditorInput) line: 1420 CompilationUnitEditor(AbstractTextEditor).lambda$1(IEditorInput, IProgressMonitor) line: 3132 2136918746.run(IProgressMonitor) line: not available WorkbenchWindow.run(boolean, boolean, IRunnableWithProgress) line: 2173 CompilationUnitEditor(AbstractTextEditor).internalInit(IWorkbenchWindow, IEditorSite, IEditorInput) line: 3149 CompilationUnitEditor(AbstractTextEditor).init(IEditorSite, IEditorInput) line: 3174 EditorReference.initialize(IWorkbenchPart) line: 362 CompatibilityEditor(CompatibilityPart).create() line: 342
(In reply to Andrey Loskutov from comment #13) > Not sure if I'm on the right track. SetContainerOperation seem always be > executed for a project on startup, and it always triggers project.touch() > which in turn sets the "hasBuildChanges" flag in WorkManager. > > ??? That code area is not my daily piece of cake, but let's see: You probably saw the comment in SetContainerOperation: // touch project to force a build if needed To me this sounds like touching should not immediately force a rebuild, but trigger it only when changes are detected ("if needed")? OTOH, javadoc of IResource.touch() contains this "If the resource is a project, the change event will indicate a description change." I'd guess that we expect the forced change to be filtered out later, perhaps based on State.wasStructurallyChanged() (see JavaBuilder.findDeltas()). If wasStructurallyChanged() answers true for no substantial reason, did s.o. unduly invoke State.tagAsStructurallyChanged()? Theory speaking, not sure if this helps ...
So, next point: SetContainerOperation seem always be executed *IF* I had the java file opened on startup. Starting with *no editors* opened doesn't trigger project.touch() and so doesn't trigger a build. For the "good" case, the oldContainer is NOT null in SetContainerOperation.executeOperation() and so the code sets modifiedProjects[i] = null; at line 87 and avoids a build. The place where the difference starts is org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(IPath, IJavaProject). In case of the editor, batchContainerInitializations() says false and we don't go inside initializeAllContainers(). We have race condition on startup? I see that if the job org.eclipse.jdt.internal.ui.InitializeAfterLoadJob.RealJob.run(IProgressMonitor) runs before all other tasks, we have no build.
Not only opened Java editor can cause a build by just resolving the JRE classpath container. Also the DynamicSourcesWorkingSetUpdater job, if executed *before* InitializeAfterLoadJob (can be just a race condition), triggers the full build: Thread [Worker-1: Update dynamic Java sources working sets] (Suspended (breakpoint at line 285 in WorkManager)) WorkManager.setBuild(boolean) line: 285 Workspace.endOperation(ISchedulingRule, boolean) line: 1476 Project(Resource).touch(IProgressMonitor) line: 1750 Project.touch(IProgressMonitor) line: 1318 SetContainerOperation.executeOperation() line: 117 SetContainerOperation(JavaModelOperation).run(IProgressMonitor) line: 733 Workspace.run(ICoreRunnable, ISchedulingRule, int, IProgressMonitor) line: 2289 Workspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor) line: 2316 SetContainerOperation(JavaModelOperation).runOperation(IProgressMonitor) line: 804 JavaModelManager.getClasspathContainer(IPath, IJavaProject) line: 2124 JavaCore.getClasspathContainer(IPath, IJavaProject) line: 3619 JavaProject.resolveClasspath(IClasspathEntry[], IClasspathEntry[], boolean, boolean) line: 3159 JavaProject.resolveClasspath(JavaModelManager$PerProjectInfo, boolean, boolean) line: 3323 JavaProject.getResolvedClasspath() line: 2400 JavaProject.buildStructure(OpenableElementInfo, IProgressMonitor, Map, IResource) line: 475 JavaProject(Openable).generateInfos(Object, HashMap, IProgressMonitor) line: 265 JavaProject(JavaElement).openWhenClosed(Object, boolean, IProgressMonitor) line: 593 JavaProject(JavaElement).getElementInfo(IProgressMonitor) line: 323 JavaProject(JavaElement).getElementInfo() line: 309 JavaProject(JavaElement).getChildren() line: 264 JavaProject.getPackageFragmentRoots() line: 2276 DynamicSourcesWorkingSetUpdater.updateElements(IWorkingSet[], IProgressMonitor) line: 198 DynamicSourcesWorkingSetUpdater.updateElements(IProgressMonitor) line: 179 DynamicSourcesWorkingSetUpdater$1.run(IProgressMonitor) line: 166 Worker.run() line: 60
Are you suggesting that SetContainerOperation should wait for s.t. like JavaModelManager.batchContainerInitializations == BATCH_INITIALIZATION_FINISHED ? S.t. like this could ensure we work only after InitializeAfterLoadJob.RealJob has completed? Still would need to detect the case when invoked from InitializeAfterLoadJob.RealJob itself. From here, a reference in corresponding tests leads me to bug 175849 - which looks closely related.
New Gerrit change created: https://git.eclipse.org/r/126441
(In reply to Eclipse Genie from comment #18) > New Gerrit change created: https://git.eclipse.org/r/126441 Just an extra tracing statement to catch the real cause of the builds. (In reply to Stephan Herrmann from comment #17) > Are you suggesting that SetContainerOperation should wait for s.t. like > JavaModelManager.batchContainerInitializations == > BATCH_INITIALIZATION_FINISHED > ? > > S.t. like this could ensure we work only after > InitializeAfterLoadJob.RealJob has completed? > > Still would need to detect the case when invoked from > InitializeAfterLoadJob.RealJob itself. Yep, something is needed here, not sure where to start. > From here, a reference in corresponding tests leads me to bug 175849 - which > looks closely related. I believe we have the same problem again, for whatever reason (have not yet analyzed the fix above).
New Gerrit change created: https://git.eclipse.org/r/126443
(In reply to Eclipse Genie from comment #20) > New Gerrit change created: https://git.eclipse.org/r/126443 I've added temporary system flag to check if we all have same issue here, and if the root cause is really "too late" initialization of classpath containers via InitializeAfterLoadJob. If -Djdt.core.NEED_BATCH_INITIALIZATION=true is specified as JVM argument for Eclipse, JDT will now *always* init loading of all containers via initializeAllContainers() on very first call to JavaModelManager.getClasspathContainer(IPath, IJavaProject). This seem to fix problems I've observed in debugger, both with/without opened Java editor. @Stephan: I would like to merge it today, so that we can check with tomorrow's SDK build with our *real* workspaces if this fixes the build problem on startup. Any objections?
Gerrit change https://git.eclipse.org/r/126441 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=c0043425904f1a4fcde903207a874506f21c971a
I see that in 4.7.2 with opened Java editor, JavaModelManager.containerPutIfInitializingWithSameEntries(IPath, IJavaProject[], IClasspathContainer[]) returns true in SetContainerOperation.executeOperation() and so no "touch" is triggered. So this is regression in 4.7.3 or 4.8. Back to the root cause: Looks like persisted access rules set for the JRE container doesn't match just created one: Put breakpoint at line 58 in org.eclipse.jdt.internal.compiler.env.AccessRuleSet.equals(Object) The "new" access set has the last entry: pattern=**/* (NON ACCESSIBLE | IGNORE IF BETTER) the "old" (persisted from previous session) access set has the last entry: pattern=**/* (ACCESSIBLE | IGNORE IF BETTER) Oops. This causes containerPutIfInitializingWithSameEntries() return false and SetContainerOperation starts to touch project.
New Gerrit change created: https://git.eclipse.org/r/126445
(In reply to Eclipse Genie from comment #24) > New Gerrit change created: https://git.eclipse.org/r/126445 This is the fix, regression is coming from bug 532505.
(In reply to Andrey Loskutov from comment #25) > (In reply to Eclipse Genie from comment #24) > > New Gerrit change created: https://git.eclipse.org/r/126445 > > This is the fix, regression is coming from bug 532505. Can you see a difference between public IAccessRule getAccessRule(IPath filePattern, int kind) { IAccessRule rule = new ClasspathAccessRule(filePattern, kind); return getFromCache(rule); } IAccessRule getAccessRule(char [] filePattern, int kind) { IAccessRule rule = new ClasspathAccessRule(filePattern, kind); return getFromCache(rule); } In Gerrit you don't, but in the IDE we have: public ClasspathAccessRule(IPath pattern, int kind) { this(pattern.toString().toCharArray(), toProblemId(kind)); } public ClasspathAccessRule(char[] pattern, int problemId) { super(pattern, problemId); } toProblemId(kind) is the key...
Gerrit change https://git.eclipse.org/r/126445 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=ba7bc984279b30ceb146292ef2cf8c63df3e1072
There's another location in State with them same problem. I'll prepare a gerrit.
New Gerrit change created: https://git.eclipse.org/r/126451
Gerrit change https://git.eclipse.org/r/126451 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=9b3ec1dae88eedd02134afe6ae9d7987b12d24cd
(In reply to Till Brychcy from comment #28) > There's another location in State with them same problem. > I'll prepare a gerrit. Thanks Till! @All who was affected by the bug: the nightly 4.9 SDK build http://download.eclipse.org/eclipse/downloads/drops4/I20180722-2000/ contains the fix, at least for ONE problem we found. This fixes rebuild issue for me in two different workspaces containing many SDK plugin projects, but I have neither XText nor m2e or other third party builders installed. Could you please test with the build above (or any later 4.9 nightly build) and check if it helps? If not, please enable tracing and attach generated log files here. Go to the Window -> Preferences -> General -> Tracing. Here "enable tracing", expand "Platform Core Resources" node and enable org.eclipse.core.resources/debug=true org.eclipse.core.resources/build/needbuildstack=true org.eclipse.core.resources/build/needbuild=true org.eclipse.core.resources/build/invoking=true org.eclipse.core.resources/build/interrupt=true
Testing the integration build of platform + jdt with a huge set of m2-projects (200+). Now startup-time (JDT-Initialization) is acceptable (30 sec. vs. 10 min). There's also a full build triggerd, but that's not neccessary because last shutdown was clean (I used the Restart-Command from the File-Menu).
Upgrading from a neon-workspace with around 500 maven-projects is as slow as before - Stacktrace of the InitRemoteEditJob-Thread: Name: Worker-13: InitRemoteEditJob State: RUNNABLE Total blocked: 921 Total waited: 31 Stack trace: java.io.WinNTFileSystem.canonicalize0(Native Method) java.io.WinNTFileSystem.canonicalize(WinNTFileSystem.java:428) java.io.File.getCanonicalPath(File.java:618) org.eclipse.jdt.internal.core.JavaProject.canonicalizedPath(JavaProject.java:328) org.eclipse.jdt.internal.core.JavaProject.getPackageFragmentRoot(JavaProject.java:2242) org.eclipse.jdt.internal.core.DeltaProcessor$RootInfo.getPackageFragmentRoot(DeltaProcessor.java:137) org.eclipse.jdt.internal.core.DeltaProcessor$RootInfo.<init>(DeltaProcessor.java:129) org.eclipse.jdt.internal.core.DeltaProcessingState.getRootInfos(DeltaProcessingState.java:340) org.eclipse.jdt.internal.core.DeltaProcessingState.initializeRoots(DeltaProcessingState.java:256) org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:730) org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:799) org.eclipse.jdt.internal.core.JavaModelManager$10.initKnownContainers(JavaModelManager.java:3121) org.eclipse.jdt.internal.core.JavaModelManager$10.run(JavaModelManager.java:3091) org.eclipse.jdt.internal.core.JavaModelManager.initializeAllContainers(JavaModelManager.java:3128) org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:2115) org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:3619) org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:3159) org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:3323) org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:2400) org.eclipse.jdt.internal.core.DeltaProcessor.createExternalArchiveDelta(DeltaProcessor.java:999) org.eclipse.jdt.internal.core.DeltaProcessor.checkExternalArchiveChanges(DeltaProcessor.java:869) org.eclipse.jdt.internal.core.DeltaProcessor.resourceChanged(DeltaProcessor.java:2078) org.eclipse.jdt.internal.core.DeltaProcessingState.resourceChanged(DeltaProcessingState.java:474) org.eclipse.core.internal.events.NotificationManager$1.run(NotificationManager.java:297) org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:287) org.eclipse.core.internal.events.NotificationManager.handleEvent(NotificationManager.java:269) org.eclipse.core.internal.resources.Workspace.broadcastEvent(Workspace.java:371) org.eclipse.core.internal.resources.Resource.refreshLocal(Resource.java:1546) org.eclipse.rse.internal.files.ui.resources.SystemRemoteEditManager.refreshRemoteEditProject(SystemRemoteEditManager.java:794) org.eclipse.rse.internal.files.ui.Activator$InitRemoteEditJob.run(Activator.java:77) org.eclipse.core.internal.jobs.Worker.run(Worker.java:60)
(In reply to Dirk Ziegenbalg from comment #33) > Upgrading from a neon-workspace with around 500 maven-projects is as slow as > before - Stacktrace of the InitRemoteEditJob-Thread: Please could we don't mix two different issues into one? *This* bug is about *unexpected* auto-builds on startup, NOT about slow build in general. Please create dedicated issue and provide steps to reproduce / thread dumps there.
The cause of this *slow* startup is the same as the full build is triggered, so this is the same issue :)
(In reply to Dirk Ziegenbalg from comment #35) > The cause of this *slow* startup is the same as the full build is triggered, > so this is the same issue :) Then please enable tracing and provide tracing output, as explained in comment 31. Please note that you have RSE installed - is this something required for your workspace? If not, please could you get rid of it, to exclude it from possible root causes?
(In reply to Andrey Loskutov from comment #36) > (In reply to Dirk Ziegenbalg from comment #35) > > The cause of this *slow* startup is the same as the full build is triggered, > > so this is the same issue :) > > Then please enable tracing and provide tracing output, as explained in > comment 31. Please note that you have RSE installed - is this something > required for your workspace? If not, please could you get rid of it, to > exclude it from possible root causes? RSE removed (I'd took a clean JavaEE-Photon-Package and did an upgrade to the integration build). Tracing enabled but no tracing-file is generated. What I'm doing wrong? Or must I close eclipse so the file is generated?
(In reply to Dirk Ziegenbalg from comment #37) > RSE removed (I'd took a clean JavaEE-Photon-Package and did an upgrade to > the integration build). Tracing enabled but no tracing-file is generated. > What I'm doing wrong? Or must I close eclipse so the file is generated? Again, we are talking about startup build. So if you want to test startup problems, you have to re-start Eclipse after enabling tracing options. But strange is it, you should have a trace file after performing some builds, at least after save/compile.
Kudos Andrey & Till!! Don't you want to mark as resolved? One definite bug has been fixed, so if ppl would still experience similar symptoms (which I hope they won't) it would most likely be a different bug, right?
(In reply to Stephan Herrmann from comment #39) > Don't you want to mark as resolved? One definite bug has been fixed, so if > ppl would still experience similar symptoms (which I hope they won't) it > would most likely be a different bug, right? You are right. @everyone still affected by unmotivated builds on startup: please file a new bug for this, with steps to reproduce using latest 4.9 nightly builds and tracing logs attached.
Will we get the bugfix in 4.8 too?
I think, not all parts where fixed. immediately after the start of eclipse an *unexpected* autobuild is triggered, even if the previous shutdown was clean. I hooked onto the eclipse project with jconsole and see a thread doing an autobuild (see the stacktrace): Name: Worker-3: Building workspace State: RUNNABLE Total blocked: 318 Total waited: 130 Stack trace: java.io.FileInputStream.open0(Native Method) java.io.FileInputStream.open(FileInputStream.java:195) java.io.FileInputStream.<init>(FileInputStream.java:138) org.eclipse.aether.internal.impl.TrackingFileManager.read(TrackingFileManager.java:65) - locked java.lang.String@6f80ad07 org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.readRepos(EnhancedLocalRepositoryManager.java:178) org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.find(EnhancedLocalRepositoryManager.java:102) org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:315) org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:224) org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:338) org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:202) org.apache.maven.project.DefaultProjectBuilder.resolveDependencies(DefaultProjectBuilder.java:212) org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:185) org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:116) org.apache.maven.project.DefaultProjectBuilder.initProject(DefaultProjectBuilder.java:652) org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:173) org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:116) org.eclipse.m2e.core.internal.embedder.MavenImpl.readMavenProject(MavenImpl.java:636) org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager$5.call(ProjectRegistryManager.java:816) org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager$5.call(ProjectRegistryManager.java:1) org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:177) org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:151) org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:99) org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.execute(ProjectRegistryManager.java:967) org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.readProjectWithDependencies(ProjectRegistryManager.java:811) org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.readProjectWithDependencies(ProjectRegistryManager.java:794) org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager$6.call(ProjectRegistryManager.java:1010) org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager$6.call(ProjectRegistryManager.java:1) com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:5065) com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3716) com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2424) com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2298) - locked com.google.common.cache.LocalCache$StrongAccessEntry@3d38ec86 com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2211) com.google.common.cache.LocalCache.get(LocalCache.java:4154) com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:5060) org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.getMavenProject(ProjectRegistryManager.java:1008) org.eclipse.m2e.core.internal.project.registry.MavenProjectFacade.getMavenProject(MavenProjectFacade.java:242) org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod$1.call(MavenBuilder.java:98) org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:177) org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:151) org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:99) org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:86) org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:200) org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:795) org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:216) org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:259) org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:312) org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:315) org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:367) org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:388) org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:142) org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:232) org.eclipse.core.internal.jobs.Worker.run(Worker.java:60) I'm trying to get a real tracefile, but it didn't work for me at this time (I don't now why). When I have a trace file, I will attach it.
Created attachment 275094 [details] trace-files for unexpected autobuild after start Finally it worked with generation of trace-files. Maybe something strange with the m2e-plugin?
(In reply to Al Bundy from comment #41) > Will we get the bugfix in 4.8 too? "Will" is future, but "4.8" is past. But don't worry, 4.9 is just around the corner (end of September).
(In reply to Dirk Ziegenbalg from comment #43) > Created attachment 275094 [details] > trace-files for unexpected autobuild after start > > Finally it worked with generation of trace-files. Maybe something strange > with the m2e-plugin? m2e is a good guess, given that your stack trace shows lots of m2e and even maven, and *no* JDT. For the rest please read comment 40.
(In reply to Stephan Herrmann from comment #45) > (In reply to Dirk Ziegenbalg from comment #43) > > Created attachment 275094 [details] > > trace-files for unexpected autobuild after start > > > > Finally it worked with generation of trace-files. Maybe something strange > > with the m2e-plugin? > > m2e is a good guess, given that your stack trace shows lots of m2e and even > maven, and *no* JDT. > > For the rest please read comment 40. But the stack trace also shows the AutoBuildJob as *root-cause*.
Pretty please, a bug was fixed in JDT, and as long as we have no evidence that the fix was wrong, the story *in this bug* is closed. AutoBuildJob is not part of JDT and hence likely indicates a separate root cause. Please file a new bug. m2e would probably be a good place to report your issue. This current bug is already in a state where future readers will be confused what actually was addressed here. For reference, the solution in this bug was discussed in comment 23 through comment 31. Anything below that line is a different bug.
Verified for 4.9 M2 with build I20180801-2000
(In reply to Dirk Ziegenbalg from comment #33) > Upgrading from a neon-workspace with around 500 maven-projects is as slow as > before - Stacktrace of the InitRemoteEditJob-Thread: > See bug 525597 for the issue of unnecessary rebuilds when restarting in workspaces with many projects. (This stack trace is another example matching those in bug 525597 comment 6)
(In reply to Till Brychcy from comment #49) > (In reply to Dirk Ziegenbalg from comment #33) > > Upgrading from a neon-workspace with around 500 maven-projects is as slow as > > before - Stacktrace of the InitRemoteEditJob-Thread: > > > > See bug 525597 for the issue of unnecessary rebuilds when restarting in > workspaces with many projects. > (This stack trace is another example matching those in bug 525597 comment 6) Tested with Build I20180808-2000. No autobuild is running now on startup, also with an older workspace which have to be migratet.
*** Bug 536891 has been marked as a duplicate of this bug. ***
