Re: Performance of JrtFileSystemProvider.exists

[Jason Zaugg]

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.

Regards,

Jason



On Thu, 16 Feb 2017 at 18:44 Alan Bateman  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":
> > https://bugs.openjdk.java.net/browse/JDK-8166236
> >
> 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
>

Re: Performance of JrtFileSystemProvider.exists

[Alan Bateman]

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":
https://bugs.openjdk.java.net/browse/JDK-8166236

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

Performance of JrtFileSystemProvider.exists

[Jason Zaugg]

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":
https://bugs.openjdk.java.net/browse/JDK-8166236

Regards,

Jason Zaugg