Le 17 sept. 08 à 12:52, David Chisnall a écrit : > I read this before implementing the version in GCKit. It is more > complex than the version in GCKit, but better suited to concurrency. > One of the goals for the GCKit implementation was determinacy - the > big advantage of refcounting over tracing is that it makes it easier > to reason about your code's performance. The GCKit code, therefore, > integrates with NSAutoreleasePool and only runs the cycle detector > when the current pool is released. This means that you never have the > GC consuming CPU time when you don't want it to. In OpenStep, this > means that the GC typically only runs between event loop iterations.
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. > On 17 Sep 2008, at 11:46, Quentin Mathé wrote: > >> Hi, >> >> I just found this paper from the IBM people that work on GC stuff >> when >> reading LtU: >> http://www.research.ibm.com/people/d/dfb/papers/Paz05Efficient.pdf >> I haven't really read it, but may be it could be interesting for >> GCKit. It looks like an improved version of the algorithm on which >> GCKit is currently based. >> The project page is here: >> http://www.research.ibm.com/people/d/dfb/recycler.html _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
