<br><br><div class="gmail_quote">On Tue, Mar 8, 2011 at 1:41 AM, Kenneth Oksanen <span dir="ltr"><<a href="mailto:cessu@iki.fi">cessu@iki.fi</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Mon, 2011-03-07 at 15:05 -0700, Joshua Warner wrote:<br>
> I actually meant uncommon in the sense of having stack-allocated<br>
> unions that participate in garbage collection.  Off the top of my<br>
> head, I could only name one language (ML) that might use a feature<br>
> like that.  Even then, I suspect most ML implementations would<br>
> actually push that stuff onto the heap.<br>
<br>
</div>Common Lisp has (declare (dynamic-extent ..)).<br>
<br>
But IMHO this is not a language-dependent issue.  Rather, whenever any<br>
language front-end using LLVM recognizes some (union) object can not<br>
outlive the call, it would be a significant optimization if LLVM would<br>
support stack-allocating the object.<br></blockquote><div><br>Point taken - but I don't think there is anything in the address-space method that would inherently prevent this.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<br>
However, note that there may be several garbage collected heaps using<br>
different garbage collectors.  Therefore the indicator for "rootness" is<br>
not merely binary.<br></blockquote><div><br>Exactly.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
> Being able to make a "marked" version of every type seems unnecessary,<br>
> and in some cases, somewhat non-intuitive.  Take for instance, making<br>
> a "marked" float type - which I can't think of any good use for.<br>
<br>
</div>Such cases may sound exotic, but perhaps not non-existing.  For example,<br>
assume one wants to write a heap that supports generating statistics of<br>
all live values, say, for the benefit of testing for memory leaks in<br>
long-running servers.  Or assume taking a snapshot of the computation<br>
onto disk and recovering it in another machine with a different<br>
representation of the (non-pointer) data type.  Or checking (by checksum<br>
exchange) whether the computational states match in a set of mutually<br>
replicating computers running in lockstep.  (I've actually done all of<br>
these, although without the involvement of LLVM.)<br>
<div><div></div><br></div></blockquote><div><br>Sounds reasonable, but does LLVM really need to support all of these cases with one big overhaul?  <br><br>-Joshua<br></div></div>