[M3devel] GC algorithm

[Daniel Alejandro Benavides D.]

Hi all:

but contemporary of the SUN's profiler article.

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:40
> Very old news. In JVM world - five
> years is a lot. 13yrs are another age :).
>  
> On May 9, 2012, at 12:36 AM, Daniel Alejandro Benavides D.
> wrote:
> 
> > 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
> >>>>>> 
> >>>>> 
> >>>> 
> >>>> 
> >> 
> >> 
> 
>