Hello,<br><br><div class="gmail_quote">2009/2/26 Talin <span dir="ltr"><<a href="mailto:viridia@gmail.com">viridia@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

The IR-level intrinsics themselves don't much help you *write* a GC, so<br>
much as to integrate one with LLVM. What is provided is essentially a<br>
mechanism for walking the stack, and a means to insert read/write<br>
barriers into the generated code, which together form a tiny fraction of<br>
what it would take to design a working collector.<br>
</blockquote><div><br><...><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
In other words, I think that it should be possible to create a fairly<br>
comprehensive and efficient collector implementation in which 80% of the<br>
implementation lives in a library, and the language front end generates<br>
the remaining 20%. Moreover, it should be possible to design this<br>
library in a way that makes it possible for people to replace<br>
significant parts of the collector, so that it can be used as a basis<br>
for developing a diverse selection of collection strategies. And because<br>
all of the parts that are specific to the object model are generated by<br>
the front-end, the collector should work for a large number of languages<br>
with different object semantics.</blockquote><div><br>IMO LLVM should try to keep its <L>ow <L>evel design. Garbage collection is already very high level.<br>A library which supports building garbage collectors on the other hand would be very helpful of course.<br>
Basically such a library boils down to an operatic system abstraction library. Functions like "stop the world" are completely managed by the OS and not the CPU. I'm not sure if such functionality is part of LLVMs goals.<br>
<br>Having that said; functions like :<br><br>- Enumerate threads<br>- Pause/Resume thread<br>- Get root pointers for a thread (including registers)<br>- Get a list of modified memory-pages (GetWriteWatch in Windows - used in the .net GC)<br>
</div></div>- ...<br><br>for different platforms - would definitely help building a GC. Just look at the source code of the Boehm GC: It's a completely unmaintainable mess of #ifdefs<br><br>A little bit off topic: Has anybody tried building a concurrent GC - running in a different _process_, instead of a thread?<br>
The idea: To perform a collection you do a fork(). The child process collects all unreferenced memory regions and reports them back to the parent process. The parrent process waits for the result (in a sperate thread) and if it gets the result it frees the memory regions.<br>
This way you do not have to worry about barriers and all the nasty stuff. The maximum pause time is close to zero.<br>Of course this is only useful with a working "copy on write" implementation of fork().<br><br>
- Ralf<br>