Thought on limiting scope of GC

Jerry jlquinn at optonline.net
Fri Feb 14 03:28:10 PST 2014


Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> writes:

> On 2/13/14, 8:41 PM, Jerry wrote:
>> Hi all,
>>
>> I just had the following thought on limiting the gc in regions.  I don't
>> know if this would address some of Manu's concerns, but here goes:
>>
>> My thought is to have something like the following:
>>
>> GC.track();
>> auto obj = allocateStuff();
>> GC.cleanup(obj);
>>
>> The idea here is that track() tells GC to explicitly track all objects
>> created from that point until the cleanup call.  The cleanup() call
>> tells gc to limit its collection to those objects allocated since the
>> track() call.  The obj parameter tells gc to consider obj live.
>>
>> This way, you can avoid tracking everything that may get created, but
>> you can limit how much work gets done.
>>
>> Comments? Slams?
>>
>> Jerry
>
> Yah, it's a classic (with the manes "track" -> "mark" and "cleanup" -> 
> "sweep"). Allocators support that already, and installing a global GC should
> do as well.

I don't follow the global GC comment.  Let's say you're using global GC
in general but want to control more tightly what it's doing at a
particular region of the code.

Mark looks at all things that have been allocated and possibly live.
Track says keep track of objects allocated after the track call, and
cleanup only looks at those objects that were recently allocated,
ignoring the rest of the heap.

If you're saying that allocators will provide the means of doing this,
then that's fine.


More information about the Digitalmars-d mailing list