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

Claes Redestad claes.redestad at oracle.com
Wed Jan 25 10:27:07 UTC 2017


this might be a pre-existing issue, but doesn't this need to take Multi-
Release JARs into account and walk the (most) appropriate subtree?



On 2017-01-24 15:35, 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

More information about the compiler-dev mailing list