(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<matth...@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 >>> > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
