Precise GC state

[Dmitry Olshansky]

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.