Granular GC

[Dmitry Olshansky]

On Saturday, 10 March 2018 at 19:53:22 UTC, Amorphorious wrote:
> The GC sucks because it requires one to use it or jump through 
> many hoops and unsafe techniques to get away from it.

I don’t see where it requires that.

>
> It would be better if we simply had more control over the GC.
>
> 1. Allow for granular GC - Multiple independent GC's that 
> handle independent parts of the D ecosystem each of which can 
> be overridden in code if desired.
>
> One GC for the main user program(allocations, etc), One for D 
> internals such as slices, One for exception handling, One for 
> lambda's/delegates, etc.

They all will have to know about each other.
This is a false separation, much like separating all odd and even 
integers to let CPU run faster.

Much more interesting one is thread-local GC, which theoretically 
would be attainable if cast to-from shared was a runtime hook.

>
> The idea is that by having better resolution each GC can be 
> tailored for it's specific purpose. For example, having a GC 
> that handles the exception handling can be tailored so that it 
> uses smaller memory and does not need to escape the memory 
> reason to scan for false pointers, etc.

Having special _allocator_ for exceptions might help, on the 
other hand recent DIP makes it refcpunted unless escaped.

Scaning still required though, exception usually contains 
message, a pointer.

> It can also does not need to be run very often and should be 
> relatively fast... in fact, if no exceptions are on the stack 
> then it should exist immediately.


No comment.

>
> Similarly, lambda and delegates would have a relatively simple 
> and fast GC since no false pointers need to be scanned, etc. In 
> fact, some simple escape analysis should allow local 
> allocations to bypass the GC.

???
Delegates by definition need to be scanned, same with lambdas. 
Also to know if something is lambda on a stack takes about the 
same time as scaning the whole stack.
Aaand once that lambda is in heap, it’s just the same old GC.


> The goal here is to still allow most of the D dependent GC 
> functionality to persist but not have to throw the baby out 
> with the bath water. E.g., keep the GC for exceptions(if it 
> still uses it), lambda's/delegates, but allow one to use manual 
> memory management for slices, or any combination one ones.  The 
> main problem with the GC is stop the world and it's scanning 
> for false pointers.

Reuniting a bunch of different GCs working as one is a nightmare, 
also the moment something is manual the rest still needs to know 
about that memory.

Stop the world usually solved by having mostly concurrent 
collector.

> But we really don't have to have an all or nothing attitude 
> which is what is forced on us by a poor design.

We don’t have that really except for exceptions and delegates.

GC can be better designed even in current constraints.