Memory management and local GC?

Ola Fosheim Grøstad ola.fosheim.grostad at gmail.com
Sat Oct 31 18:53:18 UTC 2020


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.

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".

Since a thread local GC will have less pointers to scan through, 
collection would also be faster.

Are there some practical considerations I haven't thought about?

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.



More information about the Digitalmars-d mailing list