On Wed, 2 Apr 2025 09:36:51 GMT, Alan Bateman <[email protected]> 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
