Per thread heap, GC, etc.

[Markk]

On Friday, 14 May 2021 at 15:37:22 UTC, IGotD- wrote:

> I'm very much against binding any dynamic memory to any thread. 
> It collides with a lot of programming models. For example 
> threads created outside D, in C++ or any other language has no 
> knowledge of D GC memory. This means that FFI is much more 
> complicated.

I disagree by 180°. If the memory management is associated with 
the thread, such "foreign" threads would be completely left alone 
by D or the GC, and that's exactly as it should be. Passing 
memory from/to that thread to a D thread is already a difficult 
thing to do right, this proposal would make that safer and more 
formal.

> Also threads are like prostitutes, they do the work of the 
> client and then another client comes along doing some other 
> work. Typically example are thread pools where any thread can 
> do any work.

Again, I disagree. Please read my earlier post about how the 
Allocator assignment could be scoped (e.g. by the pool 
bootstrapper) 
https://forum.dlang.org/post/mqfuxbuuhpvqeyvxoang@forum.dlang.org, Pool usage could be supported in a very natural way and be very fast, because for short tasks, the GC would never run and all the memory could be jettisoned en bloc when the thread task goes out of scope.

> Also bring fibers into the equation makes this even more 
> unfitting.

Obviously fibers need to share the same thread heap/Allocator. 
Other than that, scoping/RAII (of the pinned references) is still 
valid and this is the most important thing. The 
limitations/language guarantees would sometimes be overly strict 
between fibers of the same thread, but they are still valid. 
Fibers are scheduled cooperatively, i.e. non-preemtively, so the 
premise to make the GC simpler/faster, holds. So what is the 
problem, exactly?

> Memory bounded to a thread is a bad idea and as time moves on 
> it becomes more clear that a program should not assume which 
> thread they are running (should only operate on self) and also 
> not which CPU they are running on.

This contradicts everything I read about locality becoming more 
and more important with modern multi-core processors. The 
following is simply the best article I ever, ever read about the 
issue. I recommend reading it:

https://www.informit.com/articles/article.aspx?p=1609144

_Mark