8234805: (dc) Remove JNI upcall from DatagramChannel.receive implementation

[Chris Hegarty]

> On 26 Nov 2019, at 15:19, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 26/11/2019 15:04, Chris Hegarty wrote:
>> :
>> While there is a separate JIRA tracking some potential new benchmark tests in this area, is it possible to share what you currently have? that demonstrates the marginal improvement for the single source case. I would like to see the impact of the removal of the single cached address.
>> 
> Sure, send/receive with datagrams sizes 32/256/4096 on one platform.

I find is incredibly difficult to interpret the output of a benchmark without the source.

> The caching of the last address has not been removed, it's just moved because the SocketAddress is no longer created by the native method.

Yes, of course. I confused myself from a previous iteration of this change.

-Chris.

> 
> -Alan
> 
> Benchmark           (size)   Mode  Cnt      Score      Error  Units
> Receive.oneSender       32  thrpt    5  70835.682 ± 1502.918  ops/s
> Receive.oneSender      256  thrpt    5  67003.791 ±  996.197  ops/s
> Receive.oneSender     4096  thrpt    5  65837.507 ± 2385.990  ops/s
> Receive.twoSenders      32  thrpt    5  59499.307 ± 1178.285  ops/s
> Receive.twoSenders     256  thrpt    5  55331.224 ± 2579.388  ops/s
> Receive.twoSenders    4096  thrpt    5  52706.275 ± 1552.105  ops/s
> 
> 
> Benchmark           (size)   Mode  Cnt      Score      Error  Units
> Receive.oneSender       32  thrpt    5  71559.657 ± 1403.925  ops/s
> Receive.oneSender      256  thrpt    5  68805.549 ± 1636.508  ops/s
> Receive.oneSender     4096  thrpt    5  66726.463 ± 1241.161  ops/s
> Receive.twoSenders      32  thrpt    5  70200.264 ± 1917.967  ops/s
> Receive.twoSenders     256  thrpt    5  71248.638 ± 1638.431  ops/s
> Receive.twoSenders    4096  thrpt    5  64924.946 ± 2179.731  ops/s