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