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
