Precise GC state

Dmitry Olshansky dmitry.olsh at gmail.com
Fri Nov 24 05:53:37 UTC 2017


On Friday, 24 November 2017 at 05:34:14 UTC, Adam Wilson wrote:
> On 11/23/17 13:40, Ola Fosheim Grøstad wrote:
>> On Thursday, 23 November 2017 at 20:13:31 UTC, Adam Wilson 
>> wrote:
>>> I would focus on a generational GC first for two reasons. The
>>
>> But generational GC only makes sense if many of your GC 
>> objects have a
>> short life span. I don't think this fits well with sensible 
>> use of a
>> language like D where you typically would try to put such 
>> allocations on
>> the stack and/or use RAII or even an arena.
>>
>
> Sensible to whom? The great thing about D is that it works just 
> we well for low-level people who need to wring the most out of 
> the metal, AND the high-level productivity minded apps people, 
> who don't.
>

The problem with generational GC is “write barriers” - pieces of 
code compiler needs to insert around every write of a pointer.

Now given that we can cast pointer to integer and back (also 
unions), I don’t see how it would work unless we put write 
barriers everywhere on the off-chance it did wrote a pointer from 
OLD to NEW space.

A better GC is a great direction. Generational one is not 
feasible unless we disallow quite a few of our features.


More information about the Digitalmars-d mailing list