RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v7]

[Maurizio Cimadamore]

On Tue, 21 Jan 2025 17:04:01 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Talking to Maurizio offline, and we realized that if we just pin the continuation when we acquire the buffer, and unpin when releasing, we don't have to worry about buffers floating between threads between acquire & release, and we can also re-use the buffer in consecutive calls (like a bump allocator), meaning we just need a single buffer, instead of a two element cache, and we might be able to use it for more than 2 calls. Pinning the continuation wouldn't be a problem since we're about to do a native call any way, which will also pin it.
> 
> We would need to wait until: https://bugs.openjdk.org/browse/JDK-8347997 is fixed, which seems like a good idea either way, so we have more options when implementing this.

There's actually two strategies that are possible to avoid issues with virtual threads. The first would be the one described above - e.g. use pin/unpin. Alternatively we can use locking - e.g. acquire the allocator. Any other thread mounted on the same carrier thread will fail to acquire the allocator if already acquired -- in which case we can just return a plain confined arena (and take the performance hit). It is basically a choice as to whether we want a hit in terms of scalability _always_ (in the unlikely event of some scheduling issue), or if we want to pay for an extra CAS in the event we see the allocator acquire comes a virtual thread.

>From a code maintenance perspective, I believe it would be better to address all these issues in a centralized manner. As already discussed, we have a number of efforts in this area - for instance https://git.openjdk.org/jdk/pull/22391 It is my understanding that that PR has been closed and will be rebased on top of a more  general thread-local allocator scheme. When that happens, we can then also use the same allocator from the Linker (instead of having different mechanisms springing up in different places of the JDK).

(We do appreciate the efforts in pushing this forward though, as that helped fleshing out more of the constraints!)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23142#issuecomment-2605452325