My general impression from reading the Jones & Lin book and various papers on GC algorithms is that, in general, life becomes much less pleasant if you're the poor sap tasked with implementing a concurrent GC. Incremental GC algorithms do exist, but there's always a price to pay.
Ideally, the language can assist by using types to segregate shared mutable state from thread-local mutable state from (deep) immutable data. This enables thread-local GC as well as minimizing the performance burden of GC-related synchronization. On Thu, Feb 3, 2011 at 9:35 PM, Ben Kloosterman <[email protected]> wrote: > It was mentioned earlier that the standard library may not use copies that > may be non atomic due to the GC.. I should have asked this at the time but > is there a point ? Can you make a GC compaction or move and not stop the > world without a scheme that is incredibly costly ? For a start you must > stop the threads to scan the stack for local variables anyway not to mention > the issue of any references from other static /stack or heap data being used > by other threads ( and you cant make the reference and structure updates > atomic together without a lock) . There may be some schemes where there is > an indirection /forwarding stub left or a lookup table for heap objects > but this means your compacting is reduced and every access suffers an > indirection ( not to mention the CAS you need to avoid race conditions) . > > Ben > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
