RFR: 8352971: Increase maximum number of hold counts for ReentrantReadWriteLock

[Alan Bateman]

On Wed, 26 Mar 2025 16:19:16 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> I'm breaking this change out as a separate improvement, since it will not be generally possible to adjust these limits on the j.u.c primitives since they might already use a backing `long` to pack in information which needs to be updated atomically (would require 128-bit atomics to widen them, and it still infeasible to change return types of pre-existing APIs).

test/jdk/java/util/concurrent/tck/ReentrantReadWriteLock20Test.java line 75:

> 73:                             try {
> 74:                                 latch.await();
> 75:                             } catch (InterruptedException ie) {}

Something isn't right if any of these virtual threads are interrupted so I think failure needs to be set if there is any exception in the runnable.

test/jdk/java/util/concurrent/tck/ReentrantReadWriteLock20Test.java line 94:

> 92:                         next.join();
> 93:                     } catch (InterruptedException ie) {
> 94:                     }

I don't think we should swallow InterruptedException here. The only reason that the main thread will be interrupted here is if jtreg is trying to timeout the test, so I think it should throw when that happens.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24261#discussion_r2024466317
PR Review Comment: https://git.openjdk.org/jdk/pull/24261#discussion_r2024467711