As I see it, it's really the allocation that is more complicated with a mark-and-sweep collector (since you have to search for a correct-sized free chunk, efficiently)--the collection itself is the easy part. Actually, it seems like this is just the GC_IS_MALLOC case--that already gives us non-moving GC, and lets malloc (the system version or the Lea version) deal with managing the bookkeeping.
Allocation's more complex, but so is deallocation. Properly maintaining a free list with adjacent piece coalescing can be non-trivial, and there's the added complication of COW so multiple string headers may be pointing to the same chunk of memory, so freeing up one's not a sufficient reason to return the memory to the free pool.
Yep, I think the Lea allocator takes care of the tricky parts of the free-list management, and the GC_IS_MALLOC code is already handling the COW cases.
#2 is a bit more interesting and, if we do it right, means that we'll end up with a pluggable garbage collection system and may (possibly) be able to have type 3 threads share object arenas and memory pools, which'd be rather nice. Even if not, it leaves a good window for experimentation in allocation and collection, which isn't bad either.
This, combined with the mention of needing to drive this off of a vtable, means being able to determine the GC algorithm at runtime instead of compile-time (i.e., that was part of your point). I'm all for that--it will mean less #if's in the code, and it will make the code a bit clearer.
Yep. Care to take a shot at it?
I'll add it to my to-do list. I'm trying to finish up a few things which I've left sitting 90% done, so if someone else wants to tackle this before I get to it then go ahead--just post to the list when you start so that we don't duplicate efforts (and I'll do the same, if I get to it and no one else has started).
JEff
