Lock Contention issue

Expected behavior

Have almost no lock overhead that would trigger a possible lag source due to lock await across multiple regions.

I don't know exactly how this could even sort of work, but I feel like this a very bad limitation for the design of Folia currently. if not the most limiting issue. outside just making sure that code is optimized in here, I wonder what other sort of design could be approached.

Observed/Actual behavior

Ok, to start off, the current lock is acquired when it seems that there's not an available section, this shouldn't be an issue if there is one, because that would avoid the contention. But otherwise, the lock is global for the entire design of the system, and if it's within processes end-up costing a lot more, this is basically creating a contention across multiple regions that could potentially for example, be loading a chunk.
since this method is acquired by the addChunk( method.
now let's say that this process for some reason takes 10 milliseconds. that would mean every single region that is also trying to touch the lock, would have to wait 10 millis, and this lock contention happens across the Region Threads, so you could sort of consider this lock a database call in the "main-thread" of Paper to some point.

Another issue

This locker is also used for the markTicking and markNotTicking, which could increase extreme delays, including sort of "lag" delays that people might not be able to visualize fully if they don't have a lot of players which is the focus of Folia, so let's say that a single acquire end-up costing 200ms, this would cause lag on every single region that is also trying to tick, even though the contention on the markTick is just await time, not processing itself.

Steps/models to reproduce

Region merging, players loading chunks, things like this.

Plugin and Datapack List

.

Folia version

Latest 1.21.1 branch

Other

No response

Start by tracing the lock paths used by addChunk, markTicking, and markNotTicking, then reproduce contention during region merging or players loading chunks. Measure lock wait and processing time across region threads; the work is done when the contention and resulting delays are addressed without regressing those operations.