[M3devel] GC algorithm

[Dragiša Durić]

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