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

[Viktor Klang]

On Wed, 2 Apr 2025 09:36:51 GMT, Alan Bateman <alanb 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.

@AlanBateman Yeah, that seems sensible, I'll amend the PR.

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

@AlanBateman Yeah, that seems sensible, I'll amend the PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24261#discussion_r2024796937
PR Review Comment: https://git.openjdk.org/jdk/pull/24261#discussion_r2024796839