[M3devel] GC algorithm

Daniel Alejandro Benavides D. dabenavidesd at yahoo.es
Wed May 9 00:02:56 CEST 2012


Hi all:
for my God sake, I think is better to be useful than useless, and if that's different from general than specific, that's better, but be careful, we could loose some Boehm GC correspondence in Gcc GC, which would in turn be useful for timing and short cutting the native Modula-3 Collector, specially RTCollector SRC and perhaps the SUN test suite module (more on this later). Tony and his team did that:

http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html

Thanks in advance

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

> De: Dragiša Durić <dragisha at m3w.org>
> Asunto: Re: [M3devel] GC algorithm
> Para: "Antony Hosking" <antony.hosking at gmail.com>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: martes, 8 de mayo, 2012 16:21
> 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
> >> 
> > 
> 
> 



More information about the M3devel mailing list