NIO based SocketImpl to replace legacy PlainSocketImpl

[Bernd Eckenfels]

How will that look like on Windows, will it use IO Completion Ports? I guess scalability becomes much more of an issue with typical thousands of classic sockets.

What’s the expected performance of this? The blocking IO had a lot less latency compared to Channels, is there some regression expected or is a goal to also improve latency compared with the classic implementation?

Gruss
Bernd

Gruss
Bernd
--
http://bernd.eckenfels.net

________________________________
Von: net-dev <net-dev-bounces at openjdk.java.net> im Auftrag von Ismael Juma <ismaelj at gmail.com>
Gesendet: Dienstag, Januar 29, 2019 11:05 AM
An: Alan Bateman
Cc: nio-dev at openjdk.java.net; OpenJDK Network Dev list
Betreff: Re: NIO based SocketImpl to replace legacy PlainSocketImpl

Nice to see this, hope it works out.

Ismael

On Fri, Jan 25, 2019, 6:11 AM Alan Bateman <Alan.Bateman at oracle.com<mailto: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<http://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/20190129/2d2c8bd8/attachment-0001.html>