On Mon, 7 Apr 2025 13:55:27 GMT, Viktor Klang <vkl...@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).
>
> Viktor Klang has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains two commits:
>
> - Make sure that the test fails in case of an InterruptedException
> - Adding support for more than 65k readers and writers of
> ReentrantReadWriteLock
src/java.base/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java
line 1:
> 1: /*
@viktorklang-ora thank you so much for pushing this through!
There's a small nit: a co-worker noticed that this part of the javadoc is no
longer true:
* <h2>Implementation Notes</h2>
*
* <p>This lock supports a maximum of 65535 recursive write locks
* and 65535 read locks. Attempts to exceed these limits result in
* {@link Error} throws from locking methods.
Thanks again!
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24261#discussion_r2032392894
