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
- NIO based SocketImpl to replace legacy PlainSocketImpl Alan Bateman
-
