RFR: JDK-8171294: Slow compilation with long classpaths under JDK 9

Jonathan Gibbons jonathan.gibbons at oracle.com
Wed Feb 1 01:52:01 UTC 2017



On 01/24/2017 06:35 AM, Jan Lahoda wrote:
> Hi,
>
> As reported:
> https://bugs.openjdk.java.net/browse/JDK-8171294
> http://mail.openjdk.java.net/pipermail/compiler-dev/2016-December/010596.html 
>
>
> javac has a problem with compiling with many jars on classpath. The 
> problem is twofold:
> a) there is JavacFileManager.ArchiveContainer.pathCache, and this 
> cache keeps entries not only for path that are in the given 
> archive/jar, but also for those that are not in it, which may consume 
> too much memory
>
> b) when listing a package, for each archive/jar, an equivalent of 
> Files.exists(Path.resolve(String)) is done, which takes some time, and 
> this is repeated a lot of times (and most of the time, the package 
> does not exist in the given jar).
>
> The proposed patch is basically Maurizio's patch that lists packages 
> on opening and then can quickly decide if a given archive/jar contains 
> the given package or not. The biggest change from the original patch 
> is that the packages are computed immediately when the 
> ArchiveContainer is created, as opposed to compute them lazily. The 
> reason is that the Containers are created lazily, and are used 
> immediately after being created.
>
> Webrev:
> http://cr.openjdk.java.net/~jlahoda/8171294/webrev.00/
>
> How does this look?
>
> Thanks,
>     Jan

The basic patch looks look.

The extended discussion with respect to multi-release jars, and whether 
the jar file system is
reporting the correct packages to javac is a separate discussion.

-- Jon


More information about the compiler-dev mailing list