Improve scaling of downcalls using MemorySegments allocated with shared arenas

[Chris Vest]

Yeah, we previously also tried split counting, but reverted it because we
observed some weird rare issues, and got suspicious of it.

On Wed, Dec 10, 2025 at 8:21 AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> What I like (a lot) about this is that now we're back to using the same
> "bit" of information for both liveness and acquire count (IIUC). If
> that's the case, it would be much simpler to convince ourselves this is
> correct.
>
> Thanks
> Maurizio
>
> On 10/12/2025 14:48, Stuart Monteith wrote:
> > Thanks Chris,
> >     I've taken a look and implemented SharedSession with something
> > similar to your RefCnt. One of the differences with SharedSession is
> > that we have a separate close method. I can implement acquire0 with
> > getAndAdd(2), release0 with getAndAdd(-2) and close with
> > compareAndSwap(0, 1). With the additional tests against 0x80000001 for
> > acquire0 and release0, I have something that passes the unit tests for
> > java/foreign.
> >
> > The benchmarking is quite promising, but I'll need to look more
> > closely at it - it doesn't scale better on all platforms.
> >
> > Thanks,
> >     Stuart
> >
> >
> >
> >
> > On 08/12/2025 19:45, Chris Vest wrote:
> >> For what it's worth, in Netty we implement our reference counting
> >> with incrementing by 2 instead of 1, and use the low odd bit to
> >> indicate the released state.
> >> This allows us to acquire using getAndAdd, which scales much better
> >> than a CAS loop.
> >> Unfortunately we still need to use a CAS loop when implementing
> >> release, so that still has contention problems.
> >>
> >> For reference:
> >>
> https://urldefense.com/v3/__https://github.com/netty/netty/blob/2b29b5e87656203fecd1732ffb472a366a1918cc/common/src/main/java/io/__;!!ACWV5N9M2RV99hQ!JMRywug9hgGI_tWR1jAjiE8gIGbCfu9ZYKUrgzQiG8A3Woj6cYJa4S-ZKJ-IteJDrpe0GexRIhlFIKg6zUpWV3sr6DvTDI0$
> >> netty/util/internal/RefCnt.java#L258-L295
> >> <
> https://urldefense.com/v3/__https://github.com/netty/netty/blob/2b29b5e87656203fecd1732ffb472a366a1918cc/__;!!ACWV5N9M2RV99hQ!JMRywug9hgGI_tWR1jAjiE8gIGbCfu9ZYKUrgzQiG8A3Woj6cYJa4S-ZKJ-IteJDrpe0GexRIhlFIKg6zUpWV3sr9MgkwZk$
> >> common/src/main/java/io/netty/util/internal/RefCnt.java#L258-L295>
> >>
> >> On Mon, Dec 8, 2025 at 10:42 AM Maurizio Cimadamore
> >> <maurizio.cimadamore at oracle.com
> >> <mailto:maurizio.cimadamore at oracle.com>> wrote:
> >>
> >>
> >>      > sum() is really just a snapshot, it adds up the counters
> >> (Cells), so
> >>      > it wouldn't ensure the counter was at zero. Immediately after
> >>      > returning zero a thread could have already incremented it.
> >>     Yes. What I mean is: you can check if close() should throw
> >> because of
> >>     pending acquires. But, as I said, we can use that in any way to
> >> "block"
> >>     other acquires from happening in case we _do_ want to close. Which
> >>     leaves us exposed.
> >>      >
> >>      >
> >>      >> For the purpose of implementation clarity -- would it be
> >> useful to
> >>      >> wrap the various counters plus logic to acquire/ release (and
> >>      >> "closing" state) into a separate abstraction, which is then
> >> used by
> >>      >> SharedMemorySession? A sort of "atomic" LongAdder, if you
> >> will :-)
> >>      >>
> >>      >> That might make it easier to verify the correctness of the
> >>      >> implementation, by validating each aspect (the atomic long
> >> adder, and
> >>      >> its use from SharedMemorySession) separately.
> >>      >
> >>      > Sure, that would be a bit cleaner, thanks.
> >>
> >>     Thanks.
> >>
> >>
> >>     Maurizio
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20251212/7c4b7430/attachment.htm>