[racket-dev] gc vs assignment

(I don't quite understand why there's no extra cost for the second access, but I'll think about it and figure it out.) 

How do these costs compare then? Are we really at a point where mutation is superior to short-term allocation as far as the GC is concerned? Do you have measurements or is this something you can calculate out? 

-- Matthias




On Aug 24, 2010, at 11:43 AM, Kevin Tew wrote:

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