RFR: 8308804: Improve UUID.randomUUID performance with bulk/scalable PRNG access [v3]

[Andrei Pangin]

On Fri, 26 May 2023 08:36:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/UUID.java line 224:
>> 
>>> 222:                     // Try to pull the UUID from the current buffer at current position.
>>> 223:                     if (stamp != 0) {
>>> 224:                         int p = (int)VH_POS.getAndAdd(this, UUID_CHUNK);
>> 
>> An atomic update together with an optimistic lock looks non-idiomatic use of StampedLock to me. Won't a simple CAS loop be simpler? E.g. in pseudocode:
>> 
>> while ((p = this.pos) + 16) < buf.length) {
>>     long msb = getLong(buf, p);
>>     long lsb = getLong(buf, p + 8);
>>     if (cas(this.pos, p, p + 16)) {
>>         return new UUID(msb, lsb);
>>     }
>> }
>> 
>> // refill buffer under lock
>
> Nope, I don't think you cannot do this, because there is a race on concurrently-updating `buf`. The StampedLock (RW lock), protects the buffer-reading threads from seeing the `buf` undergoing the initialization by buffer-writing threads. Atomic pos only arbitrates the concurrent buffer-threads. That atomic does not help to resolve the buf races.

Right, my example suffers from the ABA problem. It could be likely solved by adding "generation" bits to the pos, but this will be a bit ugly. OK, let's stick with the StampedLock.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1206686499