Maybe I'm missing something here but a lock free algorithm for reference counting seems pretty trivial. As long as you can atomically increment and decrement an integer without locking you are pretty much done.
For a reference implementation of lock free reference counting on all common platforms check out boosts implementation of shared_ptr (a reference counting smart pointer designed around multithreaded use cases). >There are well known concurrent and parallel GC techniques that Hmm... I didn't really mention poor parallelism as a problem of GC. As I see it the two trade offs that have to be made for GC vs alternative techniques. The "embarrassing pause" during compaction which makes it impossible to use for applications like interactive video display that can't halt to compact a several gigabyte heap without causing stutter, and the loose memory profile. Maybe the document you sent me addresses those, and I'd be interested if it did. It's 150~ pages though so I haven't really had time to read it yet. As far as parallelism problems with GC go... the only ones I can imagine is that if you had a lot of threads going generating lots of garbage you would need to start to compact more frequently. Since compaction halts all threads, this could potentially cause very frequent compactions? Is that what you were getting at? I'd wondered about that before, but didn't know for a fact whether it came up in real world scenarios. -- http://mail.python.org/mailman/listinfo/python-list