8212132: (dc) Remove DatagramChannelImpl finalize method

[Martin Buchholz]

On Sun, Oct 27, 2019 at 11:47 PM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 27/10/2019 17:49, Martin Buchholz wrote:
>
>
> Wearing my finalization/reachability hat, it looks to me like technically
> a method like
> public int write(ByteBuffer buf)
> needs a reachabilityFence to prevent fd from being closed while in use,
> but in practice no misbehavior will ever be provoked, in part because
> hotspot refuses to hoist final fields into locals.
>
> The channel implementation has a strong reference to the FileDescriptor so
> I think you are suggesting that, at least in theory, the channel (fd,
> locks, ...) could be GC'ed while a thread is a read/write/send/receive
> method. I don't see how the compiler could look through the
> endRead/endWrite methods but I'll study it further. Also if we had issues
> here then I would expect the IBM folks to speak up as they tend to find
> them with their J9 VM.
>


I would be surprised if you could ever repro a failure due to finalization
here.
OTOH it's reasonable to try to bullet-proof methods by wrapping all public
methods that use fd in a
try { ... } finally { reachabilityFence(this); }

In j.u.concurrent, we copy final lock fields to locals because hotspot won't

final ReentrantLock stateLock = this.stateLock;
synchronized (stateLock) ...

but that refactoring will make it more likely to provoke early finalization
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20191028/b337601b/attachment.html>