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

[Alan Bateman]

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. 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.

-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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20191126/8bd7bd1d/attachment.html>