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/
?

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.

"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?

== 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.
> 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

On Friday, 13 May 2011 at 10:12:24 UTC, 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/
> ?

Release 7.0.0 of liblfds has just been published.

On Wednesday, 30 December 2015 at 23:55:25 UTC, liblfds-admin wrote:
> On Friday, 13 May 2011 at 10:12:24 UTC, 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/
>> ?
>
> Release 7.0.0 of liblfds has just been published.

Still no osx support ? or is it just not tested ?

-- Stephan

On Sunday, 3 January 2016 at 18:32:23 UTC, extrawurst wrote:
> On Wednesday, 30 December 2015 at 23:55:25 UTC, liblfds-admin
>> Release 7.0.0 of liblfds has just been published.
>
> Still no osx support ? or is it just not tested ?

Well, no build files are provided for out-of-the-box use, because I do not have an OSX platform to make them on.

The library itself will work fine on OSX of course.

It shouldn't be onerous to make the build files for it - there's nothing special that has to be done.  Just load them all up into a project and compile.

I'd very much like to support OSX and it's on my mind, but it's not reasonable to carry a Mac around the world with me for that.