Per thread heap, GC, etc.

[Markk]

On Friday, 14 May 2021 at 14:14:32 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 14 May 2021 at 13:48:12 UTC, Markk wrote:
>> Just some thoughts after reading a handful Rust and D books... 
>> and after having seen so many wrinkle their noses at GC ... 
>> and therefore, unfortunately D.
>
> What do you think of per-task GC?
>
> https://forum.dlang.org/post/yqdwgbzkmutjzfdhotst@forum.dlang.org

I think the per thread-model could be one very powerful 
implementation method for your proposal. So the two don't 
contradict each other at all, at least as far as I understand.

However, the per-thread association does more than just introduce 
a new Allocator variant. It introduces language guarantees, 
mostly through the fact that there is a stack clearly associated 
per thread and therefore clear scoping is granted (this extends 
to fibers with a bit more complexity). The other rules for that 
guarantee are described above.

The proposal would be very "D", i.e. analog to the default thread 
local static data. In the same spirit as D's thread local static 
data, it addresses concurrency issues along with memory issues 
and therefore makes it simpler to code, simpler to implement 
(non-preemtive), plus more performant at the same time.

Personally, I think introducing explicit Allocators, i.e. 
chaining them through everything as (template) parameters or 
(worse) booby trapping with sneaky overloads, makes code much 
more complex, IMHO unbearably so.

For contrast, making memory management more of a per-thread 
thing, could solve this concern too. You can easily set an 
Allocator as a per thread setting and be done with it. The 
discussed language guarantees would make sure your allocations 
are not mixed or illegally referenced across. The exact same code 
can be run under different Allocators without template code bloat 
or parametrizing overhead.

When the thread terminates (or drops out of the defining scope), 
the whole memory can be freed as a whole. The discussed language 
guarantees would make sure you have nothing mixed and dangling. 
If GC was your set Allocator, no final collection is needed, as 
you equally proposed ;-).

_Mark