RFR: 8344112: Remove code to support security manager execution mode from DatagramChannel implementation

[Alan Bateman]

On Wed, 13 Nov 2024 15:09:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Remove code required for the now defunct SecurityManager execution mode from DatagramChannelImpl. Dropping this execution mode means that untrustedReceive can be removed. Additionally, blockingReceive (used to support the adaptor) no longer needs a loop to drop datagrams that the SecurityManager rejects.
>> 
>> Once this change is in then it allow reverting some changes introduced to avoid pinning in the adaptor's receive method, a consequence of have both JEP 486 and JEP 491 integrated.
>
> src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java line 633:
> 
>> 631:                     try {
>> 632:                         SocketAddress sender = sourceSocketAddress();
>> 633:                         synchronized (p) {
> 
> I wonder if we should rip off the use of `synchronized (p)` in this method  and call
> 
>     synchronized (p) {
>        blockingReceive(p, ...);
>     }
> 
> 
> In the adaptor instead, like it used to be before virtual threads came into the picture?

Not this PR but there is a follow-up coming that will drop the dependency on DatagramPacket from DatagramChannelImpl so that it does back to the adaptor.

> src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java line 1492:
> 
>> 1490:                 Method m = AbstractSelectableChannel.class.getDeclaredMethod("forEach", Consumer.class);
>> 1491:                 m.setAccessible(true);
>> 1492:                 FOREACH = m;
> 
> Should we use this opportunity to use MethodHandle instead?

It could be changed but not related to this PR so I'd prefer not do it here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22072#discussion_r1840546535
PR Review Comment: https://git.openjdk.org/jdk/pull/22072#discussion_r1840543714