Memory management and local GC?

[Steven Schveighoffer]

On 10/31/20 2:53 PM, Ola Fosheim Grøstad wrote:
> I wonder, what is keeping D from making full use of shared?
> 
> It seems to me that if you required everything externally "referential" 
> reachable from non-thread-local globals to be typed as shared, then the 
> compiler could assume that everything allocated that is not shared 
> should go on the local GC.
> 
> If we then add reference counting for shared types, and make 
> non-thread-local class instances ref counted then we no longer need to 
> lock threads during GC collection. Then you require all shared resource 
> handlers to be reference counted class objects.

What about cycles in shared data?

Typically, when people talk about a "thread local GC", I point out that 
this doesn't help, because a thread-local GC can point at the shared GC, 
which means that you still have to stop the world to scan the shared GC.

But your idea is interesting in that there is no GC for shared data. If 
it could be made to work, it might be a nice upgrade. With a good 
reference counting system, you can also designate different memory 
management systems for different threads.

> 
> You can still hand out local GC objects to other threads if you manually 
> pin them first, can be done as a "pin-counter", or perhaps better named 
> a "borrow count".

Hm... this means that they now become shared. How does that work? 
Handing unshared references to other threads is going to be a problem.

What is the problem with allocating them shared in the first place? 
Ideally, you will NEVER transfer thread-local data to a shared context.

An exception might be immutable data. It also might make sense to move 
the data to the shared heap before sharing.

> Caveat: you have to deal with more shared protected objects.
> 
> Solution: you add an isolated pointer type that automatically allows 
> member access as long as the object has noe been actually shared yet. So 
> when you allocate a new shared object you receive it as an isolated 
> object in the global shared memory pool.
> 

This is part of the -preview=nosharedaccess switch -- you need to 
provide mechanisms on how to actually use shared data.

Such a wrapper can be written with this in mind.

-Steve