Componentizing D's garbage collector

Brad Roberts braddr at puremagic.com
Mon Jan 13 12:57:29 PST 2014


On 1/13/14 12:44 PM, Walter Bright wrote:
> On 1/12/2014 2:40 AM, Benjamin Thaut wrote:
>> Am 12.01.2014 11:27, schrieb Rainer Schuetze:
>>>
>>> I think a moving collector is currently not feasible without restricting
>>> the language a lot, probably similar to safe D and more. I'm not sure we
>>> want that in general.
>>>
>>
>> Could you give an example which part of the language would not be doable with a
>> moving collector? The only thing that comes to my mind is unions and that
>> problem can be solved by allowing the user to specify manual scanning functions
>> for structs or classes containing unions.
>>
>> Also I don't think that we can create a GC which performs as good as the one of
>> Java or C# if we are not willing to make the neccessary changes for a moving gc.
>
>
> A moving GC is already supported by D's semantics.
>
> Unions are dealt with by 'pinning' those objects, i.e. simply don't move them. I know this can work
> because I implemented a mostly copying generational collector years ago for Java. (After I invented
> this, someone else came out with a paper about a "mostly copying" collector, so I didn't get any
> credit. Oh well! But the idea is sound and it works in the real world.)

The key advantage that moving gives to a GC is to allow it to have a block of memory that it can do 
allocations out of by simply bumping the pointer.  When that region is full, a minor collection 
kicks in, moving anything still alive out to a different block of memory, then reset the region for 
re-use.  Pinned objects == region can't be emptied for reuse.  That leads to fragmentation and free 
list maintenance and you're right back with a more typical allocator.

Not to say there aren't other ways of doing things, but with random objects becoming pinnable puts a 
big damper on things unless you can identify all the objects that might be pinned and isolate them. 
  But I doubt that's really knowable up front.


More information about the Digitalmars-d mailing list