Memory management and local GC?

[IGotD-]

On Monday, 2 November 2020 at 12:28:34 UTC, Steven Schveighoffer 
wrote:
>
> What is the problem with allocating them shared in the first 
> place? Ideally, you will NEVER transfer thread-local data to a 
> shared context.
>

How would you distinguish between global and local GC allocated 
data in the language? Many times you need GC allocated data that 
can be used globally, so we need new D local key words like 
"localnew" or "globalnew".

Then since we are talking on GC operations on GC allocated memory 
should be disallowed between threads but what mechanisms does D 
have in order to prevent pure access to that data? Only 
disallowing GC operations is just going half way as I see it.

In general these multithreaded allocators usually use "stages" 
meaning that they have several memory regions to play with hoping 
that it will reduce mutex locking. Usually there is an upper 
limit how many stages you want before there isn't any performance 
advantage. Also tracking stages requires resources itself. If D 
would open up such stage for every thread, there will be a new 
stage for every thread with no upper limit. This will require 
extra metadata as well as a new region. I guess that 
implementation wise this will be complicated and also require 
even more memory than it does today.