adding rsockets support into JDK

[Lu, Yingqi]

Hi Alan,

Do you have any feedback on the approach Brian is currently drafting? Details are in the following email.

I would like to gather your feedback before continuing working on the implementation.

Thanks,
Lucy

From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Lu, Yingqi
Sent: Wednesday, September 12, 2018 10:19 PM
To: Brian Burkhalter <brian.burkhalter at oracle.com>
Cc: Aundhe, Shirish <shirish.aundhe at intel.com>; nio-dev at openjdk.java.net; Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Kaczmarek, Eric <eric.kaczmarek at intel.com>
Subject: RE: adding rsockets support into JDK

Hi Brian,

Thank you very much for your time reviewing the code and implementing all the changes.

While we are waiting for the comments from Alan and others, I will be working on cleaning up/consolidating the tests. This should be a pretty isolate task from the rest of the implementations.

Thanks,
Lucy


From: Brian Burkhalter [mailto:brian.burkhalter at oracle.com]
Sent: Wednesday, September 12, 2018 2:50 PM
To: Lu, Yingqi <yingqi.lu at intel.com<mailto:yingqi.lu at intel.com>>
Cc: Alan Bateman <Alan.Bateman at oracle.com<mailto:Alan.Bateman at oracle.com>>; nio-dev at openjdk.java.net<mailto:nio-dev at openjdk.java.net>; Viswanathan, Sandhya <sandhya.viswanathan at intel.com<mailto:sandhya.viswanathan at intel.com>>; Aundhe, Shirish <shirish.aundhe at intel.com<mailto:shirish.aundhe at intel.com>>; Kaczmarek, Eric <eric.kaczmarek at intel.com<mailto:eric.kaczmarek at intel.com>>
Subject: Re: adding rsockets support into JDK

Hi Lucy,

On Aug 29, 2018, at 5:27 AM, Alan Bateman <Alan.Bateman at oracle.com<mailto:Alan.Bateman at oracle.com>> wrote:

I've skimmed through the implementation changes in the latest webrev and it looks reasonable. The implementation is currently in the rdma.ch<http://rdma.ch/> tree and I assume you'll move that to a jdk.internal package at some point. Also it might be simpler to a simple "throws UOE" implementation in the shared directory - by this I mean the RmdaPollSelectorProvider and RdmaSocketImpl can be in the linux tree so that we aren't compiling all that code on other platforms.

I've looked over the implementation. I did not delve into the low level details, but inspired by Alan's comments I think some refactoring is needed. I've put some ideas together in the form of a webrev [1] which is generated with respect to your version 9 of the patch with my previous webrev [2] applied.

This change would move all of the existing Rdma* classes out of the share tree into the linux tree. The implementation classes are also decoupled from the jdk.net.Sockets API via reflection. I verified that with this change the only Java files which are built on macOS are RdmaProviderFactory and RdmaSocketOptions. I also verified that the code builds and all the tests pass on Linux (Ubuntu 18.04 with the librdmacm-dev package installed). Note that none of this addresses the dlopen/dlsym issue which Alan raised.

I added two packages here, jdk.net.internal and jdk.net.internal.rdma. I don't know that these are the best package names to use. Assuming however that they are OK, then maybe you would want to move all the Java code currently in the rdma.ch<http://rdma.ch> package into jdk.net.internal.rdma in the linux-only tree.

I am also wondering whether, assuming my changes in [1] or something similar were in place, some of the other reflection currently in use might be able to be removed and some of the classes consolidated. It seems that if checks are done up front in something like RdmaProviderFactory then they should not need to be redone elsewhere given that the reflection in this factory isolates the RDMA-specific code from the API points. (Note that in the RdmaProviderFactory static initializer there still needs to be added a reflective check of whether RDMA is available on the system.)

Lastly, it looks like most of the tests were copied almost verbatim from existing tests and only slightly modified. I have not investigated it but I wonder if there might be some way to keep these things more consolidated.

Please note that Alan has not seen [1] so it might be worthwhile to wait and see whether he has any comments before doing more work based on this.

Thanks,

Brian

[1] http://cr.openjdk.java.net/~bpb/8195160/webrev.09-02/
[2] http://cr.openjdk.java.net/~bpb/8195160/webrev.09-01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180914/89c569bf/attachment-0001.html>