[LLVMdev] llvm.gcroot suggestion

[Joshua Warner]

On Tue, Mar 8, 2011 at 1:41 AM, Kenneth Oksanen <cessu at iki.fi> wrote:

> 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.
>

Point taken - but I don't think there is anything in the address-space
method that would inherently prevent this.


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

Exactly.


>
> > 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.)
>
>
Sounds reasonable, but does LLVM really need to support all of these cases
with one big overhaul?

-Joshua
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110308/ce506d0d/attachment.html>