JDK 10 RFR of 8147615: (fc) FileChannelImpl has no finalizer

[Brian Burkhalter]

On Sep 4, 2017, at 4:39 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> Yes, this is hard to test as you will likely run out of file descriptors before the cleaner runs. One thing you could do is use the management API and check if the OperatingSystemMXBean is a UnixOperatingSystemMXBean as that will give you an easy way to get the maximum and open file descriptors.
> 
> As regards the patch then I assume you can skip creating the Cleaner when there is a FileInputStream or FileOutputStream parent (as they have finalizers to close the file, also a reference to the channel). If you do that then it reduces the scenarios to think about to just the FileChannels that are created directly and then unreferenced without calling close.
> 
> As regards setting the fd to -1 then this is needed to avoid the cleaner closing a file descriptor that has been recycled to another file or socket or something else. You can synchronize that code. The "what is close fails" is difficult. In other areas then failure will terminate the VM but I don't think this make sense here close might fail with EIO. Minimally EINTR will need special handling as you won't want an exception or logging for that case. The simplest might be to just for ignore and pick up again if/when logging in core libraries is examined.

Here is a version updated per the foregoing comments:

http://cr.openjdk.java.net/~bpb/8147615/webrev.01/

This continues the path taken by version .00 and does not attempt to incorporate any concept of close() on the FileDescriptor itself. In consideration of the latter it might be that the current patch represents only an interim solution.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20170905/8ad4e7b7/attachment.html>