[racket-dev] gc vs assignment

After a garbage collection all non-nursery memory is write-protected.
The first write to a page (16kB) , after a garbage collection, incurs 
the cost of unprotecting the page so it is writable and recording that 
the page has been written on.
All subsequent mutations to objects in a unprotected page do not have a 
write barrier cost, until the next garbage collection run.

At then next garbage collection all unprotected pages are 
re-write-protected and subsequent first page access will have a write 
barrier cost.

Kevin

On 08/24/2010 09:04 AM, Matthias Felleisen wrote:
> And what if they don't live in the nursery?
>
>
> On Aug 24, 2010, at 10:51 AM, Kevin Tew wrote:
>
>    
>> 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
>>>
>>>        
>> _________________________________________________
>> For list-related administrative tasks:
>> http://lists.racket-lang.org/listinfo/dev
>>