Removing The Global GC Lock: Largest Plausible Number of Threads?

[dsimcha]

== Quote from JimBob (jim at bob.com)'s article
> "dsimcha" <dsimcha at yahoo.com> wrote in message
> news:iqj8ba$18sc$1 at digitalmars.com...
> > 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