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.

But we can’t have java.base depending on jdk.management, can we?

> 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.

Good point. I understand the close() interrelationship with the parent here but overlooked this.

> 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.

Precisely.

> 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.

This concerns only the re-thrown exception at FileChannelImpl line 106 or in both invocations of invalidateAndClose()?

Thanks,

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