United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6999460 Glassfish build with JDK 6 / 7 is 5x-10x slower on Windows than on Linux
JDK-6999460 : Glassfish build with JDK 6 / 7 is 5x-10x slower on Windows than on Linux

Details
Type:
Bug
Submit Date:
2010-11-11
Status:
Closed
Updated Date:
2011-05-18
Project Name:
JDK
Resolved Date:
2011-05-18
Component:
tools
OS:
solaris_7,windows_xp
Sub-Component:
javac
CPU:
sparc,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
6u24,7
Fixed Versions:

Related Reports
Backport:
Backport:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
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.

                                    

Comments
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.
                                     
2010-11-11
EVALUATION

<deleted unnecessary comment>
                                     
2010-11-11
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.
                                     
2010-12-14
EVALUATION

http://hg.openjdk.java.net/jdk7/build/langtools/rev/a8d3eed8e247
                                     
2011-01-17



Hardware and Software, Engineered to Work Together