[LLVMdev] llvm.gcroot suggestion

Kenneth Oksanen cessu at iki.fi
Tue Mar 8 00:41:09 PST 2011


On Mon, 2011-03-07 at 15:05 -0700, Joshua Warner wrote:
> I actually meant uncommon in the sense of having stack-allocated
> unions that participate in garbage collection.  Off the top of my
> head, I could only name one language (ML) that might use a feature
> like that.  Even then, I suspect most ML implementations would
> actually push that stuff onto the heap.

Common Lisp has (declare (dynamic-extent ..)).

But IMHO this is not a language-dependent issue.  Rather, whenever any
language front-end using LLVM recognizes some (union) object can not
outlive the call, it would be a significant optimization if LLVM would
support stack-allocating the object.

>         The *real* solution is to make root-ness a function of type.
>         In other words, you can mark any type as being a root, which
>         exposes the base address of all objects of that type to the
>         garbage collector. This is essentially the same as the
>         pointer-address-space suggestion, except that it's not limited
>         to pointers. (In practice, it would only ever apply to
>         pointers and structs.)

Yes, that would be the most intuitive solution.

However, note that there may be several garbage collected heaps using
different garbage collectors.  Therefore the indicator for "rootness" is
not merely binary.

> Being able to make a "marked" version of every type seems unnecessary,
> and in some cases, somewhat non-intuitive.  Take for instance, making
> a "marked" float type - which I can't think of any good use for.

Such cases may sound exotic, but perhaps not non-existing.  For example,
assume one wants to write a heap that supports generating statistics of
all live values, say, for the benefit of testing for memory leaks in
long-running servers.  Or assume taking a snapshot of the computation
onto disk and recovering it in another machine with a different
representation of the (non-pointer) data type.  Or checking (by checksum
exchange) whether the computational states match in a set of mutually
replicating computers running in lockstep.  (I've actually done all of
these, although without the involvement of LLVM.)

-- 
; mailto:cessu at iki.fi  http://www.iki.fi/~cessu  http://cessu.blogspot.com
((lambda(a) (a a((lambda(a)(lambda()(set! a(+ a 1))a))1)))(lambda(a c)
((lambda(b) (newline)(write b)(a a((lambda(c)(lambda()(c c)))(lambda(a)
((lambda(c) (if(=(modulo c b)0)(a a)c))(c))))))(c)))) ; Scheme me!




More information about the llvm-dev mailing list