[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