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