On Sunday, 26 November 2017 at 18:58:04 UTC, jmh530 wrote:
On Sunday, 26 November 2017 at 08:49:42 UTC, Dmitry Olshansky
wrote:
If all of the code is 100% @safe (not system and not trusted)
you have a different language where write barriers would be
cheaper to implement.
Sadly you can’t “skip” write barriers in your @system code
because it may run as part of larger @safe. Which is where
they are the most costly.
I was thinking you would use a generational or precise GC for
@safe code and then fall back to the normal GC with
@system/@trusted code.
Wishful thinking. Memory flows through a program and things
allocated in @safe get passed to @system (including the last
reference cases) and vise versa.
Also in D generational hypothesis may not bear as much value due
to stack-allocation, libc heap allocations for temporaries likely
via RAII. Not to mention cheap (thread-local) Ref Counting, C++
and many other language have to use atomics which makes RC costly.
Basically the GC heap is not all of the heap, so a young objects
is even smaller part of that.
Lastly it is telling that new low-latency concurrent GCs do away
without explicit generations.
I’m thinking a more efficient way to takle temporaries would be
to add Regions to GC.
So the moment you enter a region all GC things are allocated in a
special segment, once you leave it free the segment. The last
trick is to tweak memory protection as guard pages over it. Boom!
Now if somebody touches it - DanglingPointerException :)
Not a panacea but:
- libraries using too much of GC can be controlled (unless they
build global state)
- manual memory management without memory corruption
- fast bump allocation, which is what all of sensible VM
languages do
And no need to create entire separate heap with its own
generational schema.
Not sure if that's possible or not, but in my head it would be
a separate heap from the @safe code.
And then I do append in @system on array allocated in @safe. Boom!
Certainly would be added complexity.
