RFR: 8286597: Implement PollerProvider on AIX

[Tyler Steele]

On Mon, 8 May 2023 15:24:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This PR finalizes VThreads on AIX. After the heavy lifting was done by the lovely reinrich, all that remained was to implement the abstract methods in the Poller class. This was quite straightforward after I figured out that the Pollset library does not pick up on changes to the set of fds while blocked on a poll call.
>> 
>> ### Notes
>> 
>> As mentioned above, the Pollset library won't recognize changes made to the set of fds while blocked on a call to `poll`. In order to allow the other threads to make changes to the pollset, I had to set a short (max 100ms) timeout for the call to poll in order to ensure that the pollset is refreshed. In my testing, this was a far more reliable solution than using a wakeup fd. 
>> 
>> I provided an empty implementation of two procedures in `src/hotspot/cpu/ppc/continuationHelper_ppc.inline.hpp` with some deductive work. Examining other implementations, I see they delegate this to `update_map_with_saved_link`. This is empty in `frame_ppc.inline.hpp`, so I concluded that there is nothing to do for the two continuationHelper procedures either. I wouldn't mind a second opinion on this choice.
>> 
>> The test `testSocketReadPeerClose2` in BlockingSocketOps was modified because setting so_linger doesn't cause an exception to be thrown on AIX. The underlying read call returns -1 as will other platforms, but instead of setting ECONNRESET, AIX just sets EAGAIN. I feel that this test may just not be feasible on AIX, and I've modified it accordingly.
>> 
>> I modified the timeout factor for the virtual/stress/Skynet.java test. This test passes without issue on my build & test system when run on its own, but when run as part of a test suite (eg. `make test TEST=jdk_loom`), it does not have enough time with the timeout previously specified in the test file.
>> 
>> ### Testing
>> 
>> The following tests were performed on AIX.
>> 
>> - [x] T1 tests
>> - [x] hotspot_loom w/ -XX:+VerifyContinuations
>> - [x] jdk_loom w/ -XX:+VerifyContinuations
>
> test/jdk/java/net/vthread/BlockingSocketOps.java line 198:
> 
>> 196:                         fail("read " + n);
>> 197:                     } else {
>> 198:                         assertTrue(n == -1);
> 
> This doesn't look right, read should not return -1 here.

I believe we get [here](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libnio/ch/SocketDispatcher.c#L44) with EAGAIN, but not ECONNRESET. So the -1 indicates that the read has failed.

My feeling is that the defined behaviour is not totally clear. [From setSockOpt](https://linux.die.net/man/3/setsockopt) (emphasis added by me):

> SO_LINGER
>   Lingers on a close() _if data is present_.

This does not define what happens if no data is present. In my testing, AIX behaved exactly like it does in `testSocketReadPeerClose1` so my understanding is that SO_LINGER had essentially no effect because there is no data waiting to be sent. As I see it, this test reduces to `testSocketReadPeerClose1` on AIX, so the test should be the same. Another option would be to skip it entirely on AIX.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13452#discussion_r1187683597