compiler support added for precise GC

[deadalnix]

Le 16/04/2012 04:24, Walter Bright a écrit :
> Just checked it in. Of course, it doesn't actually do precise GC, it is
> just thrown over the wall for the library devs who are itching to get
> started on it.
>
> I added a getGCInfo() method to TypeInfo that returns an
> immutable(void)*. This pointer can be anything - a pointer to data, to
> code, whatever, that implements whatever the GC might need to do precise
> collections. The value is generated by the template GCInfo(T) in object.d.
>
> Some observations:
>
> 1. if there are no pointers in the allocated data, the GCInfo(T) should
> be null. This enables a fast static check with no indirection for this
> most common case.
>
> 2. closure memory is allocated by calling _d_allocmemory. For now, it
> should just use the old conservative mark/sweep. Later, I can add a
> GCInfo(T) for it.
>
> 3. Many types will follow similar patterns:
>
> ptr .. int .. ptr .. int
>
> ptr .. ptr
>
> int .. ptr
>
> I suggest that specializations exist for these to avoid generating
> innumerable identical data structures or functions. In fact, if they are
> named with names like:
> scanpipi()
> scanpp()
> scanip()
>
> then the linker will automatically remove duplicates.
>
> 4. Stack scanning remains imprecise, and should use the usual
> conservative method.
>
> 5. The "has pointers" bit array can, of course, be eliminated.
>
> 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.
>
> Release the hounds!

BTW, what about the capability to extends the bahavior for a given type. 
I'm thinking about XOR linked list for instance.