JDK-6999460 : Glassfish build with JDK 6 / 7 is 5x-10x slower on Windows than on Linux
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 6u24,7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_7,windows_xp
  • CPU: generic,sparc
  • Submitted: 2010-11-11
  • Updated: 2011-05-18
  • Resolved: 2011-05-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u25Fixed 7 b126Fixed OpenJDK6Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
For example building the v3/web/webcore glassfish subsystem on Linux takes 47 secs.  Building it on the same dual boot machine but under Windows 7 takes 226 secs.

EVALUATION http://hg.openjdk.java.net/jdk7/build/langtools/rev/a8d3eed8e247

SUGGESTED FIX The fix is as described in the evaluation - don't call caseMapCheck for non-existant pathnames. The fix also includes some restructuring in JavacFileManager.java and Paths.java to cleanup the code and make it more efficient by reducing the number of probes of the file system by calls such as isDirectory, isFile, ... Testing: - jtreg tests: no new failures - JCK-compiler-7 lang and api tests: no new failures.

EVALUATION <deleted unnecessary comment>

EVALUATION The Glassfish build uses maven. Maven calls javac with many .jar files on the classpath. Many of these .jar files contain Manifests which contain the Class-Path attribute naming several .jar files. Starting with JDK 6, javac adds these latter .jar files onto the classpath - see 4212732. This results in javac's internal classpath containing as many as 600 jar files. This causes a drastic slowdown on Windows compared to Linux due to special handling inside javac for the Windows file system in which names are case independent. All the extra time is spent in file com/sun/tools/javac/file/JavacFilemanager.java in this method: /** Hack to make Windows case sensitive. Test whether given path * ends in a string of characters with the same case as given name. * Ignore file separators in both path and name. */ private boolean caseMapCheck(File f, RelativePath name) { : } If this method is 'disabled', then the above build on Windows takes about the same time as on Linux. This method is called for every package X directory on the classpath. However, in the Glassfish build, most of the .jar files on the classpath don't actually exist. The javac bug is that the above method is called for these non-existant .jar files, as if they were directorys. The fix is to change the callers of caseMapCheck to not call it if the classpath item does not exist.