On Tue, 21 Jan 2025 17:04:01 GMT, Jorn Vernee <jver...@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
