8223353: (ch) Change channel close implementation to not wait for I/O threads

[Chris Hegarty]

> On 6 May 2019, at 13:22, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 06/05/2019 13:18, Florian Weimer wrote:
>> :
>> But that descriptor consumes a slot in the descriptor table, which is an
>> extremely scarce resource.  It does not matter that the file description
>> used magic I/O inhibition is shared and therefore consumes very little
>> kernel resources.  The original file descriptor is still occupied until
>> the lazy close completes and cannot be reused for creating new channels.
>> 
> Sure, but that is exactly how it works since JDK 1.4. If you have a JDK 8 build handy you can trace the syscalls and see what I mean. It's exactly the same with classic networking too (also since JDK 1.4).

The changes to convert the stateLock back to using the built-in monitor
of a private Object seem ok ( from what I can tell the changes seem to
accurately anti-delta part of what was done in 8222774 [1] )

I'm trying to piece this together the other aspect of this change,
close not waiting on I/O threads. To help better understand the change
in behaviour, was it the changes for (8198562 & 8198754) [2], in
Java 11, that resulted in socket channel `close` waiting on I/O threads
to complete? Or something else ( I could be wrong as the code in this
area has changed a few times ).

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-8222774
[2] https://hg.openjdk.java.net/jdk/jdk/rev/ce06058197a4