NIO based SocketImpl to replace legacy PlainSocketImpl

[Ismael Juma]

Nice to see this, hope it works out.

Ismael

On Fri, Jan 25, 2019, 6:11 AM Alan Bateman <Alan.Bateman at oracle.com wrote:

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