[LLVMdev] Garbage Collection Project
Jon Harrop
jon at ffconsultancy.com
Thu Jun 18 00:27:54 PDT 2009
On Tuesday 16 June 2009 07:37:32 Talin wrote:
> A while back there was a discussion thread about whether an accurate,
> concurrent garbage collector could be "generic" in the sense of being
> able to support multiple different languages efficiently. After having
> done some work on this, I now believe that this is the case - using C++
> policy-based design principles, you can create a set of modules that
> represent different aspects of collector behavior (such as
> mark-and-sweep, stop-the-world, and so on) along with different aspects
> of the runtime environment (object tracing strategies, heap structures,
> threading primitives, atomics), and encode these various behaviors as
> template classes which can be bound together to create an efficient
> collector.
Hi Talin,
This is great news! I have some questions...
I had great success using some seemingly-unusual techniques in my experiments.
Firstly, rather than using a single 1 word pointer to represent a reference I
chose to use 3 words including a pointer to the type and a pointer to the
value (as well as metadata). This allows typed nulls and that addresses an
important deficiency found in most other VMs including the CLR. Is Scarcity
able to handle such references or does its implementation of stack frames
require references to be a single word?
Secondly, I used LLVM to JIT compile per-type code for garbage collection in
order to traverse data structures as efficiently as possible. Moreover, I
chose to write the entire GC in an unsafe subset of the language that I was
implementing so that I could rely upon tail calls and so forth. Does Scarcity
require the GC code to be written entirely in C?
Finally, do you have any references describing the techniques you have used to
implement a concurrent GC? I have been reading up on the subject for several
years now, with a view to implementing my own concurrent GC.
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
More information about the llvm-dev
mailing list