JDK-8153414 : (fs) Internal sun/nio/fs exceptions should be stackless
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-04-04
  • Updated: 2016-08-29
  • Resolved: 2016-04-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b114Fixed
Related Reports
Relates :  
JDK-8153229 - JavacFiler.checkFileReopening drowns in exceptions after Modular Runtime Images change
Relates :  
JDK-8154077 - (fs) Reduce number of file system classes loaded during startup
Description
Both sun.nio.fs.UnixException and sun.nio.fs.WindowsException are thrown from the native code with an error code in hands. NIO code then translates them to appropriate public exceptions, ignoring the original stack traces. In order to improve performance for methods that "normally" return non-zero errors (like Files.exists culminating in stat call), we need to make these exceptions stackless.

Benchmark:
 http://cr.openjdk.java.net/~shade/8153414/StatBench.java

Runnable JAR:
 http://cr.openjdk.java.net/~shade/8153414/benchmarks.jar

Webrev:
 http://cr.openjdk.java.net/~shade/8153414/webrev.00/
Comments
Note that JDK-8154077 has updated exists/isRegularFile/isDirectory so there aren't any exceptions thrown. There is remaining work to be done on Windows. We also need to re-examine the use of the internal exceptions, this was something we were going to fix in JDK 7 but didn't get to.
23-05-2016
Review thread: http://mail.openjdk.java.net/pipermail/nio-dev/2016-April/003627.html
08-04-2016
OK I will post the webrev as-is and await the Files.exists() prototype.
08-04-2016
I agree as Unix/WindowsException is thrown when there are failures but they will always get translated into a standard exception so the stack is not useful. Aside from the exists/notExists cases then the other usages are real failures. In time then we can eliminate the intermediate exception to speed up those cases but this is a disruptive change that we decide against doing late in JDK 7 and never got back to.
08-04-2016
I think this should be pushed regardless of Files.exists changes, because these exceptions are thrown from other methods too.
08-04-2016
I'll send you the patch that eliminate exceptions from Files.exists/notExists. It doesn't matter if we use one or several issues.
08-04-2016
Presumably the Files.exists() prototype would be the subject of a separate issue so this one may be addressed directly with the webrev supplied.
07-04-2016
Yes, we should do this. Note that we have prototyped a Files.exists that doesn't use any exceptions so there is no UnixException/WindowsException thrown.
04-04-2016