On Monday, 2 November 2020 at 14:44:08 UTC, Steven Schveighoffer wrote:
>
> You don't necessarily need to assign regions to threads. You could potentially use one region and assign different pools to different threads. If the GC doesn't need to scan shared data at all, then it's a matter of skipping the pools that aren't interesting to your local GC.
>
> As long as a pool never gets moved to another thread, you can avoid most locking.

Can't you spread the allocations out just like contemporary C-lib mallocs do in order to reduce locking? This way the GC can work just as before for the programmer. I would go for automatic solutions as far as possible without involving the programmer or changing the language.

On Monday, 2 November 2020 at 14:44:08 UTC, Steven Schveighoffer wrote:
> D has shared qualifier, which indicates whether any other thread has access to it.
>
> This is kind of the lynch pin of all these schemes. Without that enforced properly, you can't build anything.
>
> But with it enforced properly, you have options.
>
> There are still problems. Like immutable is implicitly shared. Or you can have a type which contains both shared and unshared members, where is that allocated?

There is something called separation logic, which might be interesting to look at if you are interested in this topic.

https://en.wikipedia.org/wiki/Separation_logic