[M3devel] GC algorithm

[Dragiša Durić]

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
>>>> 
>>> 
>> 
>>