Bug 159325 - [classpath] Util.getJDKLevel reading a lot of classpath jars because ClasspathEntry checks for string object reference instead of equals
Summary: [classpath] Util.getJDKLevel reading a lot of classpath jars because Classpat...
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 critical (vote)
Target Milestone: 3.2.2   Edit
Assignee: Frederic Fusier CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
: 146745 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-09-29 13:42 EDT by Raj Mandayam CLA
Modified: 2007-06-19 15:59 EDT (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Raj Mandayam CLA 2006-09-29 13:42:33 EDT
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))
Comment 1 Philipe Mulet CLA 2006-09-30 08:10:22 EDT
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.
Comment 2 Raj Mandayam CLA 2006-10-02 10:58:04 EDT
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.
Comment 3 Frederic Fusier CLA 2006-10-02 12:13:34 EDT
Philippe, OK to set target to 3.2.2 ?
Comment 4 Philipe Mulet CLA 2006-10-02 12:21:14 EDT
+1 for 3.2.2
Comment 5 Philipe Mulet CLA 2006-10-02 15:12:32 EDT
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 ?
Comment 6 Philipe Mulet CLA 2006-10-02 15:13:43 EDT
Frederic - can you pls post a 3.2.2 preview with the fix in ?
Comment 7 Chris Laffra CLA 2006-10-02 15:17:41 EDT
Sure. I can try this out.
Comment 8 Frederic Fusier CLA 2006-10-03 05:42:32 EDT
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...
Comment 9 Frederic Fusier CLA 2006-10-03 14:07:07 EDT
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
Comment 10 Steven Wasleski CLA 2006-10-05 08:55:51 EDT
Raj or Chris, could you let us know what the gain was for your large workspace scenario?
Comment 11 Raj Mandayam CLA 2006-10-05 09:01:59 EDT
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.
Comment 12 Frederic Fusier CLA 2006-10-05 10:08:42 EDT
*** Bug 159872 has been marked as a duplicate of this bug. ***
Comment 13 Frederic Fusier CLA 2006-10-29 07:33:15 EST
Comment 8 should read "Released for 3.3 M3" instead!
Comment 14 Frederic Fusier CLA 2006-10-29 07:34:22 EST
(In reply to comment #12)
> *** Bug 159872 has been marked as a duplicate of this bug. ***
> 
This is not a duplicate...
Comment 15 David Audel CLA 2007-01-15 07:06:03 EST
Verified for 3.2.2 using build M20070112-1200
Comment 16 Frederic Fusier CLA 2007-06-19 15:59:01 EDT
*** Bug 146745 has been marked as a duplicate of this bug. ***