Memory management and local GC?
Ola Fosheim Grøstad
ola.fosheim.grostad at gmail.com
Mon Nov 2 14:01:31 UTC 2020
On Monday, 2 November 2020 at 12:28:34 UTC, Steven Schveighoffer
> What about cycles in shared data?
I am making the assumption that global shared facades (caches
etc) are written by library authors that know what they do, so
they would use weak pointers where necessary.
However, your idea of using the current GC infrastructure for
sanitization could be helpful! So in development builds you could
detect such flaws at runtime during testing.
> 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.
I am making the assumption that most @safe-programmers should be
discouraged from making non-TLS globals and typically not design
their own shared facades (caches, databases etc). So that those
global "hubs" would ideally be part of a framework/library with
an underlying strategic model for parallelism.
>> 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.
Not if they are isolated. For instance, you might have a
framework for scraping websites. Then a thread hands a thread
local request object to the framework and when the framework has
fetched the data the origin thread receive the request object
with the data. You could even let the framework allocate local GC
data for the thread if the GC is written with a special pool for
Think of it like this: A @safe thread is like an actor. But there
are advanced global services at your disposal that can provide
for you using the "building materials" most useful to you (like
thread local GC memory).
> What is the problem with allocating them shared in the first
> place? Ideally, you will NEVER transfer thread-local data to a
> shared context.
I don't know if that is true. Think for instance of data-science
computations. The scientist only wants to write code in a scripty
way in his @safe thread, and receive useful stuff from the
massively parallel framework without having to deal with shared
That would be more welcoming to newbies. I think. If you could
just tell them:
1. never put things in globals unless they are immutable (lookup
2. don't deal with shared until you become more experienced.
3. use these ready made worker-frameworks for parallel computing.
> 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.
More information about the Digitalmars-d