No cardtable ? Most generational GCs use a write barrier to mark pages accessed that way only objects in accessed pages need to be checked for higher to lower generation references
http://blogs.msdn.com/b/abhinaba/archive/2009/03/02/back-to-basics-generational-garbage-collection.aspx Java does the same. Thad there are ways of massively reducing stop the world , basically by using threads and having safe points .. but those GCs are a huge task to write . For advanced GCs the stop the world is for the stack scan. Its worth noted multi threaded marks can significantly reduce GC times which can matter eg 50-100ms you may not notice but 200-400ms you will.. On Fri, Jul 12, 2013 at 2:25 AM, Patrick Walton <[email protected]> wrote: > OK, after talking with Felix and Niko (thanks!) here's a proposal. > > * Whenever we borrow an `@mut` to `&mut`, add it to a "borrowed set" for > the duration of the borrow. > > * Objects in the borrowed set are grayed before each incremental GC slice. > > * Objects in the borrowed set are scanned during each minor collection, > even if they're tenured. > > * When removing an object from the borrowed set (because the borrowed is > done), add it to a remembered set. Objects in the remembered set are > scanned during minor collections. > > * There are no other write barriers. > > I believe (although I haven't thought about it too hard) that this > suffices to make generational and incremental GC work in Rust's > mostly-copying setting. > > Patrick > > > ______________________________**_________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev> >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
