[racket-dev] gc vs assignment

Write barriers in racket3m are implemented using memory protection 
primitives provided by the OS.
Between collections we only incur a write barrier cost the first time a 
page (16k in racket) is written to.
After the first access per page, additional mutations on that page have 
no extra cost, until the gc collects again.
Mutating objects living in the nursery has no gc overhead.

Kevin

On 08/24/2010 08:18 AM, Matthias Felleisen wrote:
> Yes, I was taught the same thing in 1984. That's not the issue.
>
>
>
> On Aug 24, 2010, at 10:17 AM, Robby Findler wrote:
>
>    
>> My experience is that allocation is the primary thing to look for to
>> improve performance.
>>
>> Robby
>>
>> On Tuesday, August 24, 2010, Matthias Felleisen<matthias at ccs.neu.edu>  wrote:
>>      
>>> Catching up with some mail.
>>>
>>> Neil wrote:
>>>
>>>        
>>>> Avoiding allocation reduces GC collects, which reduces stutters and hitches.
>>>>          
>>> My (possibly old) understanding of GC and mutation tell me that this is one of those prejudices that programmers should get rid of. Every mutation goes across an access barrier in a GC like ours and can thus be much more expensive than a lightweight allocation. This was certainly true for early generational collectors. I do know that the hordes of Java programmers who invaded GCLand forced GC builders to make C/C++-like programs in Java work reasonably fast with collectors and so collectors changed.
>>>
>>> Matthew, do you know what it's really like for us?
>>> _________________________________________________
>>>   For list-related administrative tasks:
>>>   http://lists.racket-lang.org/listinfo/dev
>>>
>>>        
> _________________________________________________
>    For list-related administrative tasks:
>    http://lists.racket-lang.org/listinfo/dev
>