[External] : Re: captureCallState versus critical

[David Lloyd]

On Fri, Jul 19, 2024 at 6:03 AM Jorn Vernee <jorn.vernee at oracle.com> wrote:

> Many (all?) of the nifty solutions can be built on top of the current one.
> The problem is the allocation bottleneck, so let's focus on that first. I
> think the most straight-forward solution is to use a better allocator. The
> one in the default Arenas is quite generic. For instance, you could create
> a global free list specifically dedicated to capture state segments. (Or,
> as suggested, use the built-in Java heap allocator).
>
I agree that we can definitely build fancier APIs on top of the current one
(in fact I'm doing so).

The thing I struggle with though is that when we talk about this kind of
thing in general programming, the best solution is consistently found to be
stack allocation. For example, we allocate integer sized things on the
stack all the time. If we were using C, we would be stack allocating as a
matter of course. It seems like it should be possible for the downcall
procedure to handle this optimally using a stack allocation which is hidden
from the user. But for that to work, the downcall stub would have to eject
the values before it returns and loses its frame, which is why I jumped to
that solution. In retrospect I realize that it was a bit of an XY problem
description. The thing I really want to solve is allocation overhead, and
it feels like stack allocation should be the way.

> > thread locals and virtual threads do not get along very well, for one
> thing
>
> If the thread local was holding some kind of heavy resource, having one
> per virtual thread (of which there might be millions) would be problematic.
> For holding a single 4  to 12 byte memory segment, maybe not so much? But,
> it might also be possible for us to expose a per platform thread (not
> vthread) free list.
>

That could be interesting. For the most part when we talk about pooling
things and virtual threads, the conclusion is usually to use striping
to avoid contention and balance problems. I think the Loom team has
discussed doing more with the carrier thread, but I believe that topic is
somewhat controversial at present (or at least associated with some subtle
issues that need to be taken into account).

-- 
- DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20240722/89c43860/attachment.htm>