www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Removing The Global GC Lock: Largest Plausible Number of Threads?

reply Kagamin <spam here.lot> writes:
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/ ?
May 13 2011
parent reply dsimcha <dsimcha yahoo.com> writes:
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.
May 13 2011
parent reply "JimBob" <jim bob.com> writes:
"dsimcha" <dsimcha yahoo.com> wrote in message 
news:iqj8ba$18sc$1 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?
May 13 2011
parent dsimcha <dsimcha yahoo.com> writes:
== Quote from JimBob (jim bob.com)'s article
 "dsimcha" <dsimcha yahoo.com> wrote in message
 news:iqj8ba$18sc$1 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.

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
May 13 2011