compiler support added for precise GC

Walter Bright newshound2 at digitalmars.com
Mon Apr 16 02:25:07 PDT 2012


On 4/16/2012 2:05 AM, deadalnix wrote:
> Having this template into object.d seems problematic to me. It is now quite hard
> to provide any custom GC implementation without messing with Druntime.
>
> Providing a user created GC should be as easy as possible.

It's never going to be easy for anyone to just write their own GC, especially 
one that works better than one a lot of people have spent a lot of time on.

> I think this is again solving an implementation issue by a language design
> decision. Ultimately the useless code bloat must be handled by the toolchain
> anyway.

We gotta work with what we have.

>> 6. I suggest the GCInfo pointer be stored at the end of the allocated
>> block, as then it won't affect the alignment of the allocated data.
>>
>
> This very swap unfriendly. Many pages will have to be unswapped/swapped back in
> the marking process, even if it is 100% useless for data that doesn't contains
> pointers.

I think there's a misunderstanding. The GC allocates by powers of 2. So a 22 
byte struct will be allocated in a 32 byte block, and the GCInfo pointer can go 
at the end of that. That will not cause swapping.

As for data that has no pointers, something has to indicate that. Of course, 
another strategy is to allocate such data in separate pools. In fact, that might 
be an excellent idea, as such pools would never have to be read (i.e. swapped 
in, loaded into cache) during the mark/sweep process.


More information about the Digitalmars-d mailing list