[M3devel] GC algorithm

[Daniel Alejandro Benavides D.]

Hi all:
Dragisha I can't be quite sure what are you talking about but assuming arbitrary implementations must be the best way to talk respect of the language itself. (This is to me ask the same question but in a garbage Collector-less way)
Thanks in advance

--- El vie, 4/5/12, Dragiša Durić <dragisha at m3w.org> escribió:

> De: Dragiša Durić <dragisha at m3w.org>
> Asunto: Re: [M3devel] GC algorithm
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 4 de mayo, 2012 15:55
> .. Getting at this. Probably not a
> problem because reference is, in case when this is emitted
> by compiler, on stack/registers. As ambiguous root -
> object/page will not be altered. So, probably not race, when
> called as a hook from compiler emitted code?
> 
> On May 4, 2012, at 10: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
> > 
> 
>