Componentizing D's garbage collector

[Rainer Schuetze]

On Sunday, 12 January 2014 at 10:40:50 UTC, 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.

Maybe I'm too pessimistic ;-) I guess moving in general could be 
ok, I was thinking about segregating heaps by type 
(shared/immutable/mutable) and moving data between them adds 
restrictions. I'd like to be proven wrong.

Some thoughts regarding a moving collector:

- interfacing with C/C++ is problematic: even if a pointer is 
passed on the stack, it is not guaranteed that this stack entry 
is not modified by the called function. While this might cause 
problems when collecting memory due to this being the last 
reference to the data, it is much more likely that there are 
still references, but moving pointers will definitely fail.
Having to explicitely pin every pointer passed to C functions 
would be very expensive.

- if we have many pinned objects, compaction loses some of its 
advantages (like fast allocation). If we keep allocating from 
free lists of equal sized bins, fragmantation and memory overhead 
is limited (though not small) without moving. Also, moving lot's 
of data can also be expensive.

- interior pointers do not allow "threading" for pointer updates, 
so it might get pretty expensive to update references to moved 
objects


>
> 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.

To compete with other GCs we'd probably need write barriers to 
keep track of changed references (for concurrent operation or 
generations). There just needs to be a way to avoid having to 
rescan the full heap every time, it does not scale.

PS: my SSD with all the D stuff just died yesterday (was it a 
failure of the disks GC?). I'll probably need some time to 
recover from that...