[LLVMdev] Re: Garbage collection questions

Chris Lattner sabre at nondot.org
Tue Mar 14 11:27:58 PST 2006


Again, sorry for the delay. :(

On Thu, 9 Mar 2006, Sandro Magi wrote:
> I've written a reference-counting garbage collector for LLVM, but I'm
> still unclear on a few things.

Cool!

> The following piece of code that appears on
> http://llvm.cs.uiuc.edu/docs/GarbageCollection.html is unclear:
>
>   ;; As the pointer goes out of scope, store a null value into
>   ;; it, to indicate that the value is no longer live.
>   store %Object* null, %Object** %X
>   ...
>
> How exactly does this indicate X is no longer live? Is this internal
> code-generator logic/magic?

No, this just prevents the GC from accidentally thinking that *X is live 
through that pointer.  The collector cannot distinguish between 
pointers that are out of scope from those that aren't, so this lets it 
consider all pointers to be in scope, without causing any "dead" pointers 
to mark objects.

> The problem I'm currently unsure of, is how roots would affect
> refcounts. Should the gcread/gcwrite not be used with stack refs, etc?
>
> 1. If root refs are NOT included in the count, then objects of
> refcount 0 must be tracked in a list of scheduled deletions, but will
> be continually deferred until the root goes out of scope (the deletion
> list is filtered during a collection by the roots callback).
>
> 2. If root refs ARE included in the count, then this deferral overhead
> is avoided, at the expense of more refcount increment/decrement costs
> (on entry and exit from each function).
>
> I'm wondering which would be preferable. The collector is currently
> written assuming #1 is the case, as this is what the docs seemed to
> imply. Shall I just post the code?

I would suggest doing experiments to determine which has the higher 
overhead.  Refcounting as a whole is expensive, so you need to find a 
design that fits your constraints/application.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/




More information about the llvm-dev mailing list