On Wed, 26 Mar 2025 16:19:16 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).
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
