Componentizing D's garbage collector

[Rainer Schuetze]

On 11.01.2014 00:58, deadalnix wrote:
> On Friday, 10 January 2014 at 20:37:53 UTC, Rainer Schuetze wrote:
>> I think this might help in having different heaps (especially thread
>> local heaps if you include "shared"), but I'm not sure this works in
>> unsafe D where casting is allowed.
>>
>
> One of the key to a fast GC is segregating the heap in smaller
> parts. This is why generational collectors are so popular in java
> for instance.

> Segregating the heap imply so complications. For instance, it is
> necessary to track reference from one heap to another, typically
> from young to older objects.
>
> In D, the type system provide a natural segregation. It would be
> a great missed opportunity to not take advantage of it. This
> segregation is really nice as pointers go from one to another in
> a single direction, avoiding the need to track references
> changes, and all element of the heap part share some common
> characteristics. These characteristics allow for specialized GC
> algorithms (for instance, a GC can run on the immutable heap
> without the program even knowing about it).
>
> Casting is by essence bypassing the type system. In this case,
> you must be help responsible for what happen. The language cannot
> provide guarantees.

This might work with safe D. I haven't yet figured the consequences of 
implicit heap segregation by type. What restrictions will this impose on 
system programming?

As compacting data is also pretty problematic as long as part of the 
scanning is conservative, we might as well consider storing generation 
and type information per allocation. This will destroy some optimization 
possibilities, though.