<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>Hi Talin,</div><div><br></div><div>Interesting post,</div><div><br></div><div>On Jul 1, 2011, at 11:05 AM, Talin wrote:</div><blockquote type="cite"><div><div><b>Garbage collection is still way too difficult</b>. The biggest problem is the inability to track SSA values - it requires the </div></div></blockquote><br><blockquote type="cite"><div><div><b>Light-weight coroutines</b> would be a "nice to have", as would better <b>concurrency primitives</b>. These are things I could </div></div></blockquote><br></div><div>Tackling the "still way too difficult" and "should be more batteries included" aspects of your post, I think that there is a lot of room for an LLVM subproject that provides a "language implementors toolbox" in the form of some really well documented and standardized runtime libraries that provide GC, synchronization, etc capabilities. Having them available and reusable (and sub-settable!) would allow code sharing across a wide range of different llvm language implementation.</div><div><br></div><div>These are the capabilities that the JVM provides languages implemented on top of it, and are clearly useful. Of course the power of LLVM is that it doesn't force you to use a *particular* set of synch primitives, a particular memory management scheme, etc. However, that doesn't mean that we can't provide a toolbox of parts to choose from, just like we provide a standard optimization sequence which clients can choose to use or not.</div><div><br></div><div>-Chris</div></body></html>