8212132: (dc) Remove DatagramChannelImpl finalize method

[Alan Bateman]

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. If someone is calling close then it 
has to coordinate to any read/write or channel channel operations that 
are in flight at the time. The above is the case where the channel is 
configured non-blocking or any threads doing read/write won't block in 
syscalls. It might look unusual on first sight but allows read/write on 
channels configured non-blocking to use a single lock. Anyway, if the 
explicit close invokes the cleaner when we are guaranteed (by the 
cleaner API) that the cleaning action will never run a second time. If 
we didn't have that guaranteed then we'll need something like the 
FileDescriptorCloser.

-Alan