D Concurrent GC
Steven Schveighoffer
schveiguy at yahoo.com
Wed Sep 15 07:32:21 PDT 2010
On Wed, 15 Sep 2010 10:26:35 -0400, Sean Kelly <sean at invisibleduck.org>
wrote:
> "Steven Schveighoffer" <schveiguy at yahoo.com> wrote:
>> On Tue, 14 Sep 2010 19:09:18 -0400, Sean Kelly
>> <sean at 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
More information about the Digitalmars-d-announce
mailing list