Another virtual threads migration story: ReentrantReadWriteLock

[Andrew Haley]

On 1/29/25 16:58, Matthew Swift wrote:
> 
> Given that scaling IO to millions of concurrent IO bound tasks was one of the key motivations for vthreads, it seems a bit surprising to me that a basic concurrency building block of many applications is constrained to 64K concurrent accesses. Are you aware of this limitation and its implications?

          * Lock state is logically divided into two unsigned shorts:
          * The lower one representing the exclusive (writer) lock hold count,
          * and the upper the shared (reader) hold count.

I have no love at all for arbitrary limits, and this certainly sounds like
one. And you may be right that these days it's something that might happen
in real-world deployments.

Here's a suggestion: it shouldn't be madly difficult to rewrite the code so
that instead of an int split into two unsigned shorts, it uses a long split
into two unsigned ints. Why not give that a try, and see what happens?
Building OpenJDK on most platforms is fairly straightforward these days.

Once you have some information about how well it works in practice, it may
be appropriate to talk to Doug Lea, the author, about removing the limitation.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671