That's the mechanism, but I think Matthias's question is about the impact on performance. Assuming so, the answer is that it doesn't seem to matter much relative to everything else. Even programs that use mutation heavily don't manage to mutate many of the old-generation pages between major collections.
At Tue, 24 Aug 2010 09:43:30 -0600, 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 _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
