Another virtual threads migration story: ReentrantReadWriteLock

[Sam Pullara]

What is the deal here? You should be able to have millions of connections
or what are you doing with this whole thing?

1 million is so 2011 - WhatsApp Blog
<https://blog.whatsapp.com/1-million-is-so-2011>

On Wed, Jan 29, 2025 at 5:47 PM David Holmes <david.holmes at oracle.com>
wrote:

> On 30/01/2025 11:41 am, David Holmes wrote:
> > On 30/01/2025 4:20 am, Andrew Haley wrote:
> >> 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.
> >
> > More of a practical limit than an "arbitrary" one.  Noone was going to
> > hit 64K contending platform threads. And requiring general 64-bit atomic
> > operations back when 32-bit was still very much mainstream, would not
> > have produced an efficient implementation.
> >
> >> 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.
> >
> > Simply rebasing to extend AbstractLongQueuedSynchronizer instead of AQS,
> > as others have suggested, may "just work".
>
> Though I meant to add that I think you will run into other scalability
> issues once you are dealing with such large numbers of threads.
>
> David
> -----
>
> > Cheers,
> > David
> >
> >> 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.
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20250130/3d337e2e/attachment.htm>