<div class="gmail_quote"><div><br>Hi Talin,<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;"><div class="gmail_quote"><div>Let me ask a question before we go too much further. Currently the argument to llvm.gcroot must be an alloca instruction. You cannot GEP an internal field within the alloca and pass it to the gcroot intrinsic. So the entire alloca is considered a root, even if it has non-pointer fields. My question is, in this new address-space proposal, are we talking about changing this so that the garbage collector only "sees" the internal pointer fields within the alloca, or will it still be able to "see" the entire alloca? This is the crucial point for me - I've written my GC strategy to deal with complex allocas, and there are several data types - such as unions - which depend on this.</div>


<div><br></div><div>I can probably work around the union issue using methods like you suggest - that is building some "dummy" type containing a pointer as the long-term storage format - as long as the GC can still see the entire struct. It's ugly because it means that my frontend has to know about padding and alignment and such, issues which I prefer to leave to LLVM to figure out.</div>
</div></blockquote><div><br>Correct me if I am wrong, but to use unions without IR support means you already have to worry about padding.<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="gmail_quote">

<div><br></div><div>But if we change it so that the GC only sees pointers, then I'm dead in the water.</div></div></blockquote><div><br>In the end, the GC should only be seeing pointers anyway - some of whose "pointer-ness" depends on other values (as in the tagged union).  I think your method could still work with the GC only seeing pointers (albeit with a little modification) - the only requirement I see that your method imposes on the design of a address-space based GC strategy is to maintain information about the structure (union) containing the pointer, next to the pointer.  For this, metadata should work fine.  While it is not particularly elegant, I don't see why you would be "dead in the water" - because it could be made to work.<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="gmail_quote"><div><br></div><div>As far as my suggestion of marking types go, you are right, it doesn't make sense for most types. It really only matters for structs and pointers. Imagine if structs had an "isRoot" flag that lived next to "isPacked", which makes the struct a distinct type. This would be written in IR as "gcroot { i1, float }" or something like that. The presence of this flag has the same effect as marking a pointer in the GC address space. Combine that with the ability to mark SSA values as roots, and my life would get vastly simpler and my generated code would get about 20% faster :)</div>
<font color="#888888"><br>
</font></div></blockquote></div><br>I'm not saying this approach wouldn't work or that it is in any way worse than the address-space method, but I think it would require many more changes to how LLVM handles types.  One problem with how you are envisioning it (though not with the idea itself) is that it will probably be beneficial to be able to track multiple, independent types of roots - for example, roots for a long-term heap (where Method, Class, etc. might live) and the normal heap.  The address-space method would handle this, but the isRoot() method would have to be extended to handle distinct roots - more like isRoot(int rootId) - which would <i>really</i> complicate the type system.<br>
<br>-Joshua<br>