adding rsockets support into JDK

[Brian Burkhalter]

Hi Lucy,

On Aug 29, 2018, at 5:27 AM, Alan Bateman <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 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 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/20180912/0e276778/attachment.html>