Memory management and local GC?

[Ola Fosheim Grøstad]

On Monday, 2 November 2020 at 12:28:34 UTC, Steven Schveighoffer 
wrote:
> 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 
that purpose.

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 
himself?

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 
tables).
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.

Interesting!