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