Carmack about static analysis
Jacob Carlborg
doob at me.com
Mon Dec 26 04:53:17 PST 2011
On 2011-12-26 05:23, Andrei Alexandrescu wrote:
> On 12/25/11 8:56 PM, deadalnix wrote:
>> Le 25/12/2011 05:27, Andrei Alexandrescu a écrit :
>>> Got the GC book this morning, already read 2.5 chapters :o).
>>>
>>>
>>> Andrei
>>>
>>
>> You'll find that you can do a lot when GC is aware of immutability (in
>> functionnal languages, most things tends to be immutable).
>>
>> In the actual state of druntime, the GC is bad, but worse, cannot be
>> imporoved to take advantage of this, and never will unless a major
>> changement is done in GC interface.
>
> What changes do you have in mind?
>
> I've gone through a larger portion of the book and one thing has become
> very clear to me: we must improve the precision of the collector. This
> would be a gating feature towards taking the GC pretty much anywhere.
>
> As a first step, we must make all allocations except stack type-aware,
> and leave only the stack to be imprecise.
>
> A tactical detail of the above has become equally clear to me - we MUST
> use D's reflection and introspection capabilities in increasing the
> precision of the collector.
>
> It's fairly easy to write a generic function mark() (as in the "mark"
> stage of the mark/sweep collector) that accepts any object type with
> indirections (class, array, associative array, pointer to struct). The
> function marks the pointer and then iterates through all fields of the
> object and recurses to itself to mark other reference/pointer/etc fields
> of the object.
>
> This one generic function obviates a lot of the code necessary today for
> conservatively marking pointers, and also reduces and simplifies
> enormously the new code that would otherwise be needed in order to
> define precise collection.
>
> Pointers to instances of that generic functions would be accessible from
> each allocated block; to transitively mark the block, the function is
> called via pointer.
>
> Essentially instances of that function (which I estimate to a 50-liner)
> would take care of mark() for the entire universe of D types - a
> humongous success of compile-time reflection.
>
>
> Andrei
What about the parallel/concurrent collector that has been linked a
couple of times in this newsgroup. Would that be possible and a good
idea to implement?
--
/Jacob Carlborg
More information about the Digitalmars-d
mailing list