[LLVMdev] Garbage collection

Nicolas Geoffray nicolas.geoffray at lip6.fr
Mon Mar 2 02:20:39 PST 2009


Hi Talin,

First of, thanks for generating such an interesting discussion on 
garbage collection!

> For example, I mentioned the "stop the world" function - however since 
> LLVM defines no primitives for creating threads or synchronizing between 
> them, its hard to see how this could be part of LLVM proper. 

So LLVM should not be aware of "stop the world" stuff. It's really a 
matter of your collector. What LLVM should be aware is the position of 
safe points in the code. That's the case with Gordon's GCStrategy class. 
However, to implement "stop the world", runtimes should be able to add 
runtime-specific code at these safe points. If you could, then adding a 
cooperative, stop-the-world GC would be straightforward. Just poll a 
variable during the safe-point. When a collection is required, the 
collector updates that variable and waits for all threads to poll it.

After Gordon's *fantastic* work on GC interfaces in LLVM, I think that's 
the one thing missing in the design. The other intrinsics let you 
generate code that should be GC-independent and only need GC 
implementations. So you can start right away writing your collector(s) :)

> On the 
> other hand, a sibling project (like vmkit or clang) could probably make 
> a more restrictive set of assumptions, such as the existence of either 
> POSIX or Windows threading models or some analog of those being 
> available. "Stop the world" is implementable in terms of those threading 
> primitives if you assume that mutator threads use sync points.
>   

That's right!

> Thus, it seems to me that the proper home for such a function would be 
> in a sibling project outside of LLVM proper. At the same time, however, 
> core LLVM could benefit from having an implementation of this, in that 
> it could guide the design of the IR by providing more concrete use cases 
> for things like inserting sync points in generated code and such.
>   

There is a runtime directory in llvm, maybe that's where memory and 
threading examples could be added? However, a real-world GC is no piece 
of cake and way out of the scope of LLVM. So I like the idea of a 
sibling project. The runtime directory should just contain simple 
implementations.

Nicolas



More information about the llvm-dev mailing list