[M3devel] GC algorithm

[Dragiša Durić]

Got that. You pointed write barrier to me few yrs ago, and that's it.

I am reading through RTCollector.m3 in pieces of time I have to spare. Lots of legacy code there. Any good reaosn to keep several different functionalities in single source module? Like RTWeakRef, lots of differentable mutator/collector code and so on?

On May 8, 2012, at 11:12 PM, Antony Hosking wrote:

> Just following up quickly while extremely rushed.
> Indeed, the fact that the mutator has the references on its stack will cause their targets to be pinned (not copied) if a collection intervenes between the marking and before the store.  So, they will be retained.
> 
> On May 4, 2012, at 4:37 PM, Dragiša Durić wrote:
> 
>> I am not very fluent with RTCollector source, but it looks to me there is at least one possible race condition situation possible.
>> 
>> RTHooks.CheckStoreTraced() explicitly marks object & its page dirty/not-clean. Everything with heap locked. But - next thing is - heaps is unlocked and this method returns. What if collector from other thread "hijacks" heap right at end of CheckStoreTraced()/well before mutator changes some reference field in object? 
>> 
>> Similar situaction is with "read barrier" in CheckLoadTraceRef(). Or at least it looks like one to me :).
>> 
>> dd
>> 
>