RFR 15 8243099: Adding ADQ support to JDK

Alan Bateman Alan.Bateman at oracle.com
Sat Apr 18 15:40:10 UTC 2020


On 18/04/2020 00:13, Ivanov, Vladimir A wrote:
> Hello everyone,
> I would like to add support for the Application Device Queue (ADQ) technology to the JDK.
>
> The JBS entry and webrev were created for this improvement:
> JBS: https://bugs.openjdk.java.net/browse/JDK-8243099
> Webrev: http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.00/
>
> Please let us know your feedback and comments for this enhancement.
>

Just to put more context on this. Vladimir brought this to nio-dev in 
March with some background and initial proposed it as a standard socket 
option [1]. A socket option that allows an application to split incoming 
flows based on their receive queue is very Linux specific so we 
suggested it should be in the JDK-specific ExtendedSocketOptions API 
with the other non-standard socket options.

net-dev is the right mailing list to progress this and get a sponsor 
(maybe Sandhya Viswanathan will do it?). We can probably drop 
core-libs-dev from the this one.

Just a few comments on the current webrev:

The API docs in the webrev is a good start but will need to be fleshed 
out as it uses several terms such as "device queue", "last frame", "Rx 
queue" without any definition. One important point that we will need to 
be covered is that it's a read-only socket option so the docs will need 
to specify the exception that will be thrown when trying to set it. From 
a quick look at the implementation then it appears to fall through to 
InternalError so that might need to be fixed. It will also be important 
to document the socket types and where in their lifecycle (listening, 
connected) that the socket option can be used.

Will SO_INCOMING_NAPI_ID be defined in a header file? It probably needs 
#ifndef to avoid the hardcoded value when building on distributions that 
define it. A passing comment is that native methods static methods so 
"unused" is a jclass.

Tests. Read-only socket options might trip up on existing tests in the 
jdk_net or jdk_nio test groups that enumerate all socket options and 
exercise get and set on each one. The proposed test will probably go 
several iterations to get to something that is maintainable. It will 
also need to be extended to exercise SocketChannel, ServerSocketChannel 
and more.

-Alan

[1] https://mail.openjdk.java.net/pipermail/nio-dev/2020-March/007109.html


More information about the core-libs-dev mailing list