8212132: (dc) Remove DatagramChannelImpl finalize method

[Martin Buchholz]

On Sat, Oct 26, 2019 at 9:41 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

>
>
> On 25/10/2019 17:46, Martin Buchholz wrote:
> > The Cleaner code looks good to me.
> Thanks.
>
> >
> > Of course, ensuring the concurrency correctness of this code is a much
> > harder problem.  I was especially frightened when I saw
> >
> > 1259         // wait for any read/write operations to complete before
> > trying to close
> > 1260         readLock.lock();
> > 1261         readLock.unlock();
> > 1262         writeLock.lock();
> > 1263         writeLock.unlock();
> > 1264         synchronized (stateLock) {
> >
> > I have come to think of GC finalization as yet another mutual
> > exclusion problem - between the object and the patient GC vulture
> > waiting to collect it and call its cleaner.
> We haven't changed anything here.


Right.  I'm just an interested bystander musing about the complexity of
concurrency and finalization.
(No need to respond.)
Because I think of finalization as a mutual exclusion problem with the GC,
I am thinking "this class is dealing with 4 different locks"

(also, there's no read-write-lock as one would expect from seeing a
readLock and a writeLock.  But I have no better name (hmmm   maybe
readerLock and writerLock?))

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20191027/22ecf998/attachment.html>