[racket-dev] gc vs assignment

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