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.
