[LLVMdev] More Garbage Collection Questions

[Gordon Henriksen]

On 2007-09-15, at 23:55, Talin wrote:

> Gordon Henriksen wrote:
>
>> Can you be more specific the algorithm for which you need type  
>> metadata in a write barrier? No algorithms I am aware of perform  
>> any tracing from a write barrier.
>
> This one does:
>
> http://citeseer.ist.psu.edu/cache/papers/cs2/442/ 
> http:zSzzSzwww.cs.technion.ac.ilzSz~erezzSzPaperszSzms-sliding- 
> views.pdf/an-on-the-fly.pdf
>
>> Write barriers are commonly used to record references from old- 
>> generation objects to new-generation ones, either by recording the  
>> referencing object, the referencing field, or using a card table.  
>> For these purposes, the addresses are sufficient.
>
> In the paper cited above, the write barrier checks to see if the  
> object being mutated has been traced; If it hasn't, then it records  
> the values of all pointers contained in the object into a buffer -  
> for which you need the location of the pointers.

Okay. If you're implementing this algorithm with a tagless collector,  
we may need to extend the intrinsics.

>> In concurrent collectors—by which I mean those that run  
>> asynchronously of the mutator—write barriers may be used to mark  
>> the written object pointer. Even byte arrays as you describe  
>> require an object header in which to store mark bits, else the  
>> collector cannot know whether the object has been marked (mark- 
>> sweep collectors) or copied (copying collectors).
>
> In my design, the mark bits are maintained by the allocator as part  
> of the allocation header of each memory block.
>
> In other words, I'm trying to maintain a strict separation between  
> the allocator/collector and the actual objects stored in the heap.  
> The allocator/collector "owns" all of the bits that are before the  
> start address of the object, while the language-specific type  
> system owns all of the bits after the start address. As a result  
> the collector isn't tied to a specific language.

Sure. So by design, type metadata is never necessary to access the  
mark bits.

— Gordon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070916/6a38e052/attachment.html>