Le 17 sept. 08 à 15:01, David Chisnall a écrit :

> On 17 Sep 2008, at 13:46, Quentin Mathé wrote:
>
>> ok. Do you imply that the algorithm detailed in this paper is more
>> tracing-inspired than the one in GCKit though? I mean, if you  
>> consider
>> that the cycle detection in GCKit simulates tracing by scanning the
>> refcounts inside the cycle.
>
> Tracing and cycle detection with reference counting are both
> degenerate cases of the same general algorithm (see the Unified Theory
> paper by the same guys - probably the only paper on GC I would make
> recommended reading for everyone thinking about programming).

Yes. I was indeed thinking about the Unified Theory paper when I wrote  
that.

> The
> approach described in this paper is likely to be slightly faster than
> the current approach.  It has two disadvantages:
>
> 1) It's concurrent, meaning that existing threads will be preempted to
> run the GC when the number of threads is greater than the number of
> processor cores.
>
> 2) It's concurrent, meaning that any implementation is likely to be
> buggy, difficult to test, and almost impossible to prove correct.
> Finding bugs in the sequential version was hard enough...
>
> If (when we actually start using GCKit for anything) it is problematic
> in terms of performance then I'll consider implementing the concurrent
> version, but until then it doesn't seem worth it.  I have not done any
> serious benchmarks with CGKit, however it's worth noting that the
> scanner will only be run on an object when:
>
> - It is released but not dealloc'd and
> - It still exists when the current autorelease pool is destroyed.
>
> This means that it is only likely to be run on a very small subset of
> all objects.  Making it concurrent is likely to cost more from the
> extra context switches than it saves.

I see. All that makes sense.

> I will, however, add a hardware implementation to my feature wish-list
> for my next CPU ;-)

No problem ;-)

Quentin.





_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev

Reply via email to