Community
Participate
Working Groups
In a product based on WTP with large number of plugins, I opened a workspace with 70 j2ee projects, when I build the workspace, I found a lot of I/O taking place (like 10gb) We found that the following method was reading a lot of bytes Thread [Worker-11] (Suspended) ZipFile.open(String, int, long) line: not available [native method] ZipFile.<init>(File, int) line: 203 ZipFile.<init>(File) line: 234 JavaModelManager.getZipFile(IPath) line: 1751 Util.getJdkLevel(Object) line: 814 ClasspathEntry.validateClasspathEntry(IJavaProject, IClasspathEntry, boolean, boolean) line: 1642 JavaProject.getResolvedClasspath(IClasspathEntry[], IPath, boolean, boolean, Map) line: 2182 JavaProject.getResolvedClasspath(boolean, boolean, boolean) line: 2073 DeltaProcessor.updateClasspathMarkers(IResourceDelta, HashSet, Map, Map) line: 2107 DeltaProcessor.updateClasspathMarkers(IResourceDelta, HashSet, Map, Map) line: 2137 DeltaProcessor.updateClasspathMarkers(IResourceDelta, DeltaProcessingState$ProjectUpdateInfo[]) line: 2153 DeltaProcessor.resourceChanged(IResourceChangeEvent) line: 1855 DeltaProcessingState.resourceChanged(IResourceChangeEvent) line: 444 NotificationManager$2.run() line: 280 SafeRunner.run(ISafeRunnable) line: 37 NotificationManager.notify(ResourceChangeListenerList$ListenerEntry[], IResourceChangeEvent, boolean) line: 274 NotificationManager.broadcastChanges(ElementTree, ResourceChangeEvent, boolean) line: 148 Workspace.broadcastBuildEvent(Object, int, int) line: 240 AutoBuildJob.doBuild(IProgressMonitor) line: 142 AutoBuildJob.run(IProgressMonitor) line: 208 Worker.run() line: 58 Looking at the code in ClasspathEntry.java case IClasspathEntry.CPE_LIBRARY : if (path != null && path.isAbsolute() && !path.isEmpty()) { IPath sourceAttachment = entry.getSourceAttachmentPath(); Object target = JavaModel.getTarget(workspaceRoot, path, true); if (target != null && project.getOption(JavaCore.CORE_INCOMPATIBLE_JDK_LEVEL, true) != JavaCore.IGNORE) { long projectTargetJDK = CompilerOptions.versionToJdkLevel(project.getOption(JavaCore.COMPILER_CODEGEN_TARGET_PLATFORM, true)); long libraryJDK = Util.getJdkLevel(target); if (libraryJDK != 0 && libraryJDK > projectTargetJDK) { return new JavaModelStatus(IJavaModelStatusConstants.INCOMPATIBLE_JDK_LEVEL, project, path, CompilerOptions.versionFromJdkLevel(libraryJDK)); } } The if block is evaluating to true if (target != null && project.getOption(JavaCore.CORE_INCOMPATIBLE_JDK_LEVEL, true) != JavaCore.IGNORE) { I found, target was not null AND both project.getOption(JavaCore.CORE_INCOMPATIBLE_JDK_LEVEL, true) AND JavaCore.IGNORE to be of the value "ignore" But looks like JDT is doing object reference check instead of .equals based checking thats why (project.getOption(JavaCore.CORE_INCOMPATIBLE_JDK_LEVEL, true) != JavaCore.IGNORE) is evaluating to true Should it not be !(project.getOption(JavaCore.CORE_INCOMPATIBLE_JDK_LEVEL, true).equals(JavaCore.IGNORE))
Excellent find, we shouldn't be using identity compare here. Frederic - pls check other instances (all refs to CompilerOptions fields). May want to backport to 3.2.2, since this may be a big performance issue for some usecases.
We need this fix to be targeted for 3.2.2 (if not any lower) because the product depends on this version. Hence raising it to critical.
Philippe, OK to set target to 3.2.2 ?
+1 for 3.2.2
Chris - Can you double check the fix has the nice consequences we expect in term of performance ? i.e. Do we get stuck again elsewhere after this ?
Frederic - can you pls post a 3.2.2 preview with the fix in ?
Sure. I can try this out.
Released for 3.3 M2 in HEAD stream. Test cases added in ClasspathTests: - #testClasspathValidation27_Bug159325_project() - #testClasspathValidation27_Bug159325_lib() Backport to 3.2.2 will be done today...
Released for 3.2.2 in R3_2_maintenance stream. I've posted corresponding preview at: http://www.eclipse.org/jdt/core/r3.2/index.php#UPDATES
Raj or Chris, could you let us know what the gain was for your large workspace scenario?
Hi Steve, Before this fix, I would see in 10 min of building the workspace I/O Read bytes grow to 10 gb, after the fix, in 10 min I/O Read bytes is at 1-2 gb. So really good improvement.
*** Bug 159872 has been marked as a duplicate of this bug. ***
Comment 8 should read "Released for 3.3 M3" instead!
(In reply to comment #12) > *** Bug 159872 has been marked as a duplicate of this bug. *** > This is not a duplicate...
Verified for 3.2.2 using build M20070112-1200
*** Bug 146745 has been marked as a duplicate of this bug. ***