Not quite ready for prime-time yet, but I think it's in a stage when it
could be interesting anyway (at least for developers or people that want
to experiment):
http://llucax.com.ar/blog/blog/post/-1a4bdfba


If you like history, you can read all the related posts in chronological
order here:
http://llucax.com.ar/blog/blog/tag/dgc?sort=+date

If you only care about concurrency, you probably want to read just this: http://llucax.com.ar/blog/blog/tag/cdgc?sort=+date

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Desde chiquito quería ser doctor
Pero después me enfermé y me hice músico

Very nice. I've been reading your posts on this with interest.

How much work would be involved in porting this to druntime?

Bernard Helyer, el 10 de septiembre a las 04:49 me escribiste:
> Very nice. I've been reading your posts on this with interest.
> 
> How much work would be involved in porting this to druntime?

Is hard to tell since I didn't followed druntime development very closely lately, but both are based on the same code, so probably not too much work should be involved.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
In a world without fences, who need gates?

Leandro Lucarella Wrote:

> Not quite ready for prime-time yet, but I think it's in a stage when it
> could be interesting anyway (at least for developers or people that want
> to experiment):
> http://llucax.com.ar/blog/blog/post/-1a4bdfba

Nice work!  I've gotten this to compile as the GC for druntime using D2 but have ran into a snag.  I'm using OSX (ie. no usable debug info) but near as I can tell the issue is:

private T locked(T, alias Code)()
{
    if (thread_needLock())
        synchronized (gc.lock) return Code();
    else
       return Code();
}

void* gc_malloc(size_t size, uint attrs = 0)
{
    if (size == 0)
        return null;
    return locked!(void*, () {
        assert (Invariant()); scope (exit) assert (Invariant());
        return malloc(size, attrs, null);
    })();
}

In the code above, it appears that the anonymous delegate being passed as an alias to locked() is having its stack data dynamically allocated (ie. as a dynamic closure).  For normal delegate calls this can be avoided by accepting "scope delegate" as the function parameter, but I haven't found an analog when using the alias approach.  Obviously, what happens is that a call to gc_malloc() ends up needing GCed memory, so gc_malloc() is recursively called, and on until the stack explodes.  I'll see if I can come up with a workaround that continues using the alias template parameter.

On Tue, 14 Sep 2010 19:09:18 -0400, Sean Kelly <sean@invisibleduck.org> wrote:

> Leandro Lucarella Wrote:
>
>> Not quite ready for prime-time yet, but I think it's in a stage when it
>> could be interesting anyway (at least for developers or people that want
>> to experiment):
>> http://llucax.com.ar/blog/blog/post/-1a4bdfba
>
> Nice work!  I've gotten this to compile as the GC for druntime using D2 but have ran into a snag.  I'm using OSX (ie. no usable debug info) but near as I can tell the issue is:
>
> private T locked(T, alias Code)()
> {
>     if (thread_needLock())
>         synchronized (gc.lock) return Code();
>     else
>        return Code();
> }
>
> void* gc_malloc(size_t size, uint attrs = 0)
> {
>     if (size == 0)
>         return null;
>     return locked!(void*, () {
>         assert (Invariant()); scope (exit) assert (Invariant());
>         return malloc(size, attrs, null);
>     })();
> }
>
> In the code above, it appears that the anonymous delegate being passed as an alias to locked() is having its stack data dynamically allocated (ie. as a dynamic closure).  For normal delegate calls this can be avoided by accepting "scope delegate" as the function parameter, but I haven't found an analog when using the alias approach.  Obviously, what happens is that a call to gc_malloc() ends up needing GCed memory, so gc_malloc() is recursively called, and on until the stack explodes.  I'll see if I can come up with a workaround that continues using the alias template parameter.

What if you passed it through a scope delegate function?

i.e.

void *lockedproxy(scope void* delegate() dg)
{
  return locked!(void *, dg);
}

-Steve

"Steven Schveighoffer" <schveiguy@yahoo.com> wrote:
> On Tue, 14 Sep 2010 19:09:18 -0400, Sean Kelly <sean@invisibleduck.org>  wrote:
> 
>> Leandro Lucarella Wrote:
>> 
>>> Not quite ready for prime-time yet, but I think it's in a stage when
> > > it
>>> could be interesting anyway (at least for developers or people that
> > > want
>>> to experiment): http://llucax.com.ar/blog/blog/post/-1a4bdfba
>> 
>> Nice work!  I've gotten this to compile as the GC for druntime using
> > D2  > but have ran into a snag.  I'm using OSX (ie. no usable debug info) but  > near as I can tell the issue is:
>> 
>> private T locked(T, alias Code)()
>> {
>>     if (thread_needLock())
>>         synchronized (gc.lock) return Code();
>>     else
>>        return Code();
>> }
>> 
>> void* gc_malloc(size_t size, uint attrs = 0)
>> {
>>     if (size == 0)
>>         return null;
>>     return locked!(void*, () {
>>         assert (Invariant()); scope (exit) assert (Invariant());
>>         return malloc(size, attrs, null);
>>     })();
>> }
>> 
>> In the code above, it appears that the anonymous delegate being
> > passed  > as an alias to locked() is having its stack data dynamically allocated  > (ie. as a dynamic closure).  For normal delegate calls this can be  > avoided by accepting "scope delegate" as the function parameter, but I  > haven't found an analog when using the alias approach.  Obviously, what  > happens is that a call to gc_malloc() ends up needing GCed memory, so  > gc_malloc() is recursively called, and on until the stack explodes.   > I'll see if I can come up with a workaround that continues using the  > alias template parameter.
> 
> What if you passed it through a scope delegate function?
> 
> i.e.
> 
> void *lockedproxy(scope void* delegate() dg)
> {
>   return locked!(void *, dg);
> }

I could simply change it to a function that accepts a scope delegate. It just isn't as efficient as the alias approach.  But an indirect call is pretty small potatoes in this case anyway. I tried this and it worked, and the I ran into an issue where the object used for the lock (classinfo for GCLock) was apparently null. I'll look into that today.

On Wed, 15 Sep 2010 10:26:35 -0400, Sean Kelly <sean@invisibleduck.org> wrote:

> "Steven Schveighoffer" <schveiguy@yahoo.com> wrote:
>> On Tue, 14 Sep 2010 19:09:18 -0400, Sean Kelly
>> <sean@invisibleduck.org>  wrote:
>>
>>> Leandro Lucarella Wrote:
>>>
>>>> Not quite ready for prime-time yet, but I think it's in a stage when
>> > > it
>>>> could be interesting anyway (at least for developers or people that
>> > > want
>>>> to experiment):
>>>> http://llucax.com.ar/blog/blog/post/-1a4bdfba
>>>
>>> Nice work!  I've gotten this to compile as the GC for druntime using
>> > D2  > but have ran into a snag.  I'm using OSX (ie. no usable debug
>> > info) but  > near as I can tell the issue is:
>>>
>>> private T locked(T, alias Code)()
>>> {
>>>     if (thread_needLock())
>>>         synchronized (gc.lock) return Code();
>>>     else
>>>        return Code();
>>> }
>>>
>>> void* gc_malloc(size_t size, uint attrs = 0)
>>> {
>>>     if (size == 0)
>>>         return null;
>>>     return locked!(void*, () {
>>>         assert (Invariant()); scope (exit) assert (Invariant());
>>>         return malloc(size, attrs, null);
>>>     })();
>>> }
>>>
>>> In the code above, it appears that the anonymous delegate being
>> > passed  > as an alias to locked() is having its stack data
>> > dynamically allocated  > (ie. as a dynamic closure).  For normal
>> > delegate calls this can be  > avoided by accepting "scope delegate"
>> > as the function parameter, but I  > haven't found an analog when
>> > using the alias approach.  Obviously, what  > happens is that a call
>> > to gc_malloc() ends up needing GCed memory, so  > gc_malloc() is
>> > recursively called, and on until the stack explodes.   > I'll see if
>> > I can come up with a workaround that continues using the  > alias
>> > template parameter.
>>
>> What if you passed it through a scope delegate function?
>>
>> i.e.
>>
>> void *lockedproxy(scope void* delegate() dg)
>> {
>>   return locked!(void *, dg);
>> }
>
> I could simply change it to a function that accepts a scope delegate. It
> just isn't as efficient as the alias approach.  But an indirect call is
> pretty small potatoes in this case anyway. I tried this and it worked,
> and the I ran into an issue where the object used for the lock
> (classinfo for GCLock) was apparently null. I'll look into that today.

Well, the alias version could be used for other callable types, whereas a delegate version can only be used for delegates.  Not sure how important it is.

-Steve

Steven Schveighoffer Wrote:

> On Wed, 15 Sep 2010 10:26:35 -0400, Sean Kelly <sean@invisibleduck.org> wrote:
> 
> >
> > I could simply change it to a function that accepts a scope delegate. It just isn't as efficient as the alias approach.  But an indirect call is pretty small potatoes in this case anyway. I tried this and it worked, and the I ran into an issue where the object used for the lock (classinfo for GCLock) was apparently null. I'll look into that today.
> 
> Well, the alias version could be used for other callable types, whereas a delegate version can only be used for delegates.  Not sure how important it is.

I think there needs to be a solution for this in the general case, but for this specific application it doesn't matter.

Sean Kelly Wrote:

> Leandro Lucarella Wrote:
> 
> > Not quite ready for prime-time yet, but I think it's in a stage when it
> > could be interesting anyway (at least for developers or people that want
> > to experiment):
> > http://llucax.com.ar/blog/blog/post/-1a4bdfba
> 
> Nice work!  I've gotten this to compile as the GC for druntime using D2 but have ran into a snag.

Okay, all fixed.  Porting the GC to D2 was more work than porting it to druntime specifically.  There are still a few hacks in place to work around const issues and I faked the PointerMap stuff, but the GC seems to work just great.  I'll have to find a reasonable performance test for comparison.  Oh, I'll send you the modified code as well.

Sean Kelly wrote:

> Sean Kelly Wrote:
> 
>> Leandro Lucarella Wrote:
>> 
>> > Not quite ready for prime-time yet, but I think it's in a stage when it
>> > could be interesting anyway (at least for developers or people that want
>> > to experiment):
>> > http://llucax.com.ar/blog/blog/post/-1a4bdfba
>> 
>> Nice work!  I've gotten this to compile as the GC for druntime using D2 but have ran into a snag.
> 
> Okay, all fixed.  Porting the GC to D2 was more work than porting it to druntime specifically.  There are still a few hacks in place to work around const issues and I faked the PointerMap stuff, but the GC seems to work just great.  I'll have to find a reasonable performance test for comparison.  Oh, I'll send you the modified code as well.

Are you going to integrate it in druntime?