Performance of JrtFileSystemProvider.exists

Jason Zaugg jzaugg at
Thu Feb 16 22:43:55 UTC 2017

Thanks, Alan. Good to hear that this is on the radar.

In the meantime, I think I can solve our performance problem by using the
/packages namespace to route lookups to the relevant module(s) to avoid so
many negative lookups in the first place.



On Thu, 16 Feb 2017 at 18:44 Alan Bateman <Alan.Bateman at> wrote:

> On 16/02/2017 08:15, Jason Zaugg wrote:
> > Recently I modified the Scala compiler to read class files
> > jrt:/ filesystem, rather than relying on rt.jar.
> >
> > I noticed a slowdown when running on JDK 9 ea and exercising this code.
> > Profiles suggest that the bottleneck is in calls to Files.exists.
> > JrtFileSystemProvider inherits an implementation which needs to
> construct,
> > throw and catch NoSuchFileException to answer in the negative.
> >
> > It is possible that I'm calling this more often than needed, and could
> > implement a caching layer. But it seems worthwhile for jrtfs to
> implement a
> > fast path for exists, as is done in UnixFileSystemProvider.
> >
> > Possibly related bug "Startup regression with Jython":
> >
> >
> As it happens, we a similar issue with the zip provider. It's something
> that I was looking at with Sherman recently and we have a proposal to
> push the exists down to the provider interface so that it can be
> overridden.
> So a different issues to JDK-8166236 - that one is that Jython seems to
> create a cache on first usage of all classes that it finds in rt.jar. I
> assume that if/when Jython adds support for JDK 9 and jrtfs that they
> will be able to integrate it with their caching.
> -Alan

More information about the jigsaw-dev mailing list