• Amorphorious (36/36) Mar 10 2018 The GC sucks because it requires one to use it or jump through
• Dmitry Olshansky (24/54) Mar 10 2018 They all will have to know about each other.

Amorphorious <Amorphorious gmail.com> writes:

The GC sucks because it requires one to use it or jump through 
many hoops and unsafe techniques to get away from it.

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.

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

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.

What these do is reduce the overhead that might trigger a 
complete GC scan for no real purpose other than that is the way 
the current GC is designed.

When new GC topologies are added they simply replace the old. The 
main idea is to granularize the GC which simply requires 
modifying the compiler to use the specific GC(e.g., when slices 
are allocated, instead of allocating with the GC, it allocates 
with GC.Slices, or whatever).

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. But we really don't have to have an all or nothing 
attitude which is what is forced on us by a poor design.

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

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.