RFR: 8312166: (dc) DatagramChannel's socket adaptor does not release carrier thread when blocking in receive [v2]

[Jaikiran Pai]

On Wed, 19 Jul 2023 10:31:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> DatagramChannel is "virtual thread friendly"; when configured blocking, the receive/read methods release the carrier when there is no datagram to receive.
>> 
>> DatagramChannel's socket adaptor (used by DatagramSocket) is not currently virtual thread friendly. The original changes proposed to address this in JDK 19 interacted with the carrier thread's buffer cache so we decided to not include them at the time. The change proposed here are to address this issue, mostly by moving the implementation of the socket adaptor's send/receive methods into the DatagramChannel implementation so that a temporary direct buffer is not held when parked.
>> 
>> The only observable change should be to silly/broken code that changes a DatagramPacket's buffer (with setData or setLength) while a receive is in progress. Long standing, and undocumented, behavior would for setXXX to block while a receive is in progress, new behavior will be only access the DatagramPacket's buffer when a datagram is received. I can't think of anything that could rely on behavior like this.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Ensure SocketTimeoutException is thrown when SM set
>  - Merge
>  - Merge
>  - Initial commit

test/jdk/java/net/DatagramSocket/TimeoutWithSM.java line 63:

> 61:                     System.out.println("checkAccept " + isa);
> 62:                     if (isa.equals(sender)) {
> 63:                         throw new SecurityException();

Given that the goal of this test is to exercise the case where the `SecurityManager` rejects incoming packets and then times out the receive call, would it be better to just throw `SecurityException` here for all host/port combinations instead of checking the sender?

We have had cases, in the CI, where stray datagrams have been received in test cases from unexpected senders. In such cases this test will still fail, but with the assertion error that it received an unexpected packet . Throwing `SecurityException` for all addresses here, would avoid intermittent failures and in theory the test would then only get a `SocketTimeoutException`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14901#discussion_r1267941124