[LLVMdev] More Garbage Collection Questions

[Gordon Henriksen]

Hi Talin,

On 2007-09-16, at 13:28, Talin wrote:

> More accurately, what I am trying to do is not only create a  
> collector, but also create a framework for implementing different  
> collector algorithms. I don't intend to be the person that creates  
> the best/fastest collector, I just want to create something that  
> people can build on.

You might want to read this, which documents the work I've recently  
done[*] to LLVM's compile-time GC support (pending review):

   http://homepage.mac.com/malichus/GarbageCollection.html

However, I am explicitly not authoring a collector runtime, so our  
work may not be overlapping at all. My immediate goal is to support  
code generation for an existing collector.

> There are a lot of algorithms out there that require similar  
> underlying data structures - an efficient heap, lock-free work  
> queues, and so on. I figure if I can provide those along with a  
> working example, it may help to stimulate further development.

Sounds good.

> I chose this particular algorithm to start with because it seemed  
> fairly easy to implement.

This section might be interesting to you:

   http://homepage.mac.com/malichus/GarbageCollection.html#collector- 
algos

Threaded programs and concurrent collectors are the most challenging  
for the compiler, and LLVM does not (even with my patches) provide  
sufficient compile-time support for them, so they may not be the best  
starting point.

Two of the more tricky aspects which pose a challenge to getting  
started with a GC algorithm are the stack walker and "stop-the-world"  
algorithms. Libraries to support those would be very cool.

> Eventually I want to do a multi-generation design - most of the  
> research papers out there seem to settle on a per-thread copying  
> collector for young generations, and a heap-based mark and sweep  
> for older generations. However,  tracking references to young  
> generation objects belonging to a different thread is quite  
> involved, and I wanted to start off with something less challenging.
>
> One thing I am missing is a way to test this in an LLVM context.  
> Right now all my tests are just unit tests. I'd like to do a full  
> integration test - to be able to actually write LLVM programs that  
> work with my heap - but I don't want to have to write a whole  
> language compiler to do it.

I'm not sure there's another way to usefully create large codes for  
test.

— Gordon


[*] If you want the code, a recent copy of the patch set is here:  
http://homepage.mac.com/malichus/gc.3.zip




— Gordon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070916/25bccded/attachment.html>