== Quote from JimBob ([email protected])'s article > "dsimcha" <[email protected]> wrote in message > news:[email protected]... > > On 5/13/2011 6:12 AM, Kagamin wrote: > >> dsimcha Wrote: > >> > >>> I'm thinking about ways to remove the global lock from the garbage > >>> collector for most small allocations. I'm basically thinking of making > >>> the free lists thread local. > >> > >> http://www.liblfds.org/ > >> ? > > > > Surprisingly, lock-free free lists wouldn't solve the problem, since the > > GC flag bookkeeping would still require locking unless it is completely > > rewritten. > If the flag needs to be atomicaly updated and thread local free lists solve > that problem yet global lock free free lists dont, the implication is that > the flag is only ever accessed from the one thread. And that implies that > memory cant be allocated in one thread and freed in another?
There's clearly been some misunderstanding here because I haven't explained in detail what my idea was. First, the GC would still be locked when sweeping or manually freeing. Second, every page would be owned by a single thread. The way the GCBits are laid out, this means the flags issue would become a non-issue because every integer that makes up the bit array only tracks flags for one page. Secondly, I'm concerned about two things if I get too fancy with lock-free/atomic stuff: 1. It might plausibly end up being substantially slower than the current version in single-threaded programs or programs where there's not much contention. 2. I don't want to do anything too clever. I learned the hard way by implementing std.parallelism that: non-trivial manual memory management + clever concurrency in the same code == nightmarish to debug
