NIO based SocketImpl to replace legacy PlainSocketImpl

[Alan Bateman]

I've created a branch in the sandbox, named "niosocketimpl-branch", with 
a prototype SocketImpl implementation based on the infrastructure in 
sun.nio.ch package that supports the NIO channel implementations. The 
branch also includes the changes to java.net.Socket and ServerSocket to 
use this SocketImpl by default.

There are several motivations for this prototype: The existing 
PlainSocketImpl is not fit for purpose in the potential future world of 
fibers that park instead of blocking carrier threads in syscalls. As I'm 
sure most people are on net-dev are aware, PlainSocketImpl is horrible 
to maintain due to the complexity of the code paths in its native 
methods. Replacing PlainSocketImpl, along with its associates 
SocketInputStream and SocketOutputStream, bring other benefits such as 
not needing to use the thread stack for I/O and not needing the fd table 
data structure to support asynchronous close.

We have to be a cautious about replacing the PlainSocket/SIS/SOS after 
20 years of service. It is likely that there is behavior in unspecified 
areas and corner case scenarios that existing applications or libraries 
may depend upon. There is performance work to do but it's possible there 
are cases where the performance might degrade, e.g. many years ago there 
were attempts to fix a synchronization issue in PlainSocketImpl that 
lead to complaints from usages involving hundreds of threads blocking on 
ServerSocket::accept. To that end, we are planning to evolve the 
prototype to allow the old and new SocketImpls to co-exist, maybe 
switched by a system property or some other means. Going there may 
require a bit yak shaving, for example in the SOCKS and HTTP proxy 
implementations as they need to be re-worked to forward rather than 
sub-class. If the prototype goes further then the idea is that both 
implementations could be included in the JDK for a few releases before 
removing the old code.

The prototype doesn't have a replacement for PlainDagramSocketImpl at 
this time. There are a few issues around how legacy MulticastSocket 
behaves that will take a bit of time to sort out. Ideally its 
replacement will use the same infrastructure as the DatgramChannel 
implementation as that supports modern muilticasting features and is a 
lot easier to maintain.

For now, we (= Michael McMahon and myself for now) will iterate on this 
prototype in the sandbox. If we go forward with it then we'll likely 
create a JEP.

-Alan