digitalmars.D - Re: Removing The Global GC Lock: Largest Plausible Number of Threads?
- Kagamin <spam here.lot> May 13 2011
- dsimcha <dsimcha yahoo.com> May 13 2011
- "JimBob" <jim bob.com> May 13 2011
- dsimcha <dsimcha yahoo.com> May 13 2011
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
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
"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
== 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