8278371: Scalability bottleneck in NativePRNG

[dwhite-intel]

RandomIO.implNextBytes() in NativePRNG class can become a bottleneck at high contention. This shows up as the hotest lock in SPECjvm crypto.rsa benchmark.

This can be reduced by doing less work in the "synchronized (LOCK_GET_BYTES)" block.

Initial fix is to remove the array allocation out of the synchronized block.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issue

• JDK-8278371: Scalability bottleneck in NativePRNG

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/6757/head:pull/6757
$ git checkout pull/6757

Update a local copy of the PR:
$ git checkout pull/6757
$ git pull https://git.openjdk.java.net/jdk pull/6757/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 6757

View PR using the GUI difftool:
$ git pr show -t 6757

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/6757.diff

[bridgekeeper]

👋 Welcome back drwhite! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@dwhite-intel The following label will be automatically applied to this pull request:

• security

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 00: Full (966ff5e5)

[shipilev]

This probably makes non-contended case a bit slower: Arrays.copyOfRange intrinsic are quite likely allocating the destination array without zeroing. The explicit allocation probably does zeroing everywhere.

It seems to me that this is a scenario for read-write-lock. The buffer replenishes should be guarded by write lock (as they modify the nextBuffer), and buffer copies-from should be guarded by read lock (as they only read from it). This leaves the question of buffered that needs to be updated, but that one might be a singular atomic variable.

[dwhite-intel]

OK, Thanks Aleksey!

We just noticed some performance differences either due to different CPUs or different baseline (still detangling), so your comment about copyOfRange may be related.

The point of this patch was a (theoretically) easy fix to get into JDK 18.

We have some thoughts on a full fix by either bypassing the global buffer or bypassing /dev/random. This will involve consulting with a few parties - not for JDK 18 :-)

I'll update and leave the JBS issue open, but close this PR.