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.
