[M3devel] GC algorithm

[Daniel Alejandro Benavides D.]

Hi all:
OK, understood, I think this kind of philosophy is smoother:
http://static.usenix.org/events/coots99/full_papers/liang/liang.pdf

Similarly the CM JVM  can be applied to this test too.

Look at this old news (it seems they didn't believe it that much, probably that's why they never released it):
http://www.informationweek.com/newsflash/nf655/1105_st9.htm

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: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> CC: "Antony Hosking" <antony.hosking at gmail.com>, "m3devel" <m3devel at elegosoft.com>
> Fecha: martes, 8 de mayo, 2012 17:20
> G1 collector sounds interesting, and
> funny. Pause prediction - good luck with that.
> 
> Fast sweep through blurb on that page and I think this
> collector of theirs is a bit behind what we have in
> Modula-3. No wonder - Modula-3 had what they are describing
> and few things more years before Java existed.
> 
> Interesting tidbit, maybe. If they can collect with multiple
> threads at same time, that _is_ something new. But they
> danced around that on that page.
> 
> Also, G1 is not what Antony and his team did. They made
> real-time collector, and G1 is not. I think link was posted
> here some time ago.
> 
> On May 9, 2012, at 12:02 AM, Daniel Alejandro Benavides D.
> wrote:
> 
> > 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
> >>>> 
> >>> 
> >> 
> >> 
> 
>