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
