Even 4K is probably too large most card tables are 128 or 256 bytes . Im pretty sure memory protection has been tried but i cant recall the paper. I do know Azul pauseless/concurrent collector uses the MMU but this is more for cocurrent mark/sweep reasons. They had an issue because which pages to be protected change and the kernel could not handle all the system calls so they have a long running request ( so far denied) to change the syscall ( or add one) to specify a collection of pages.
Ben >One issue I see with relying on memory protection to fix up write >barriers is that you are effectively tying yourself to 4 kB pages. >You won't be able to use huge pages (2 or 4 MB) because those are >simply too large to scan in a reasonable amount of time. On Thu, Jul 25, 2013 at 6:02 PM, Ben Noordhuis <[email protected]> wrote: > Sorry about reviving an oldish thread, I hadn't seen it before. > > On Wed, Jul 10, 2013 at 8:32 PM, Patrick Walton <[email protected]> > wrote: > > For generational GC, we must ensure that objects in the nursery pointed > to > > by the tenured generation are either added to a remembered set or > tenured. > > This is harder in Rust because we have to know both the generation of the > > referrer and the referent simultaneously. I believe that conservatively > > tenuring all objects that are mutated would be overconservative and > defeat > > much of the purpose of GGC. > > > > The only thing that I can think of that would work is to use the MMU and > do > > the generational GC barriers on a per-page basis. I believe that this is > > what Boehm does in its GGC mode. This to me seems the most risky part of > > this; I'm not sure what the performance implications of this are. > > One issue I see with relying on memory protection to fix up write > barriers is that you are effectively tying yourself to 4 kB pages. > You won't be able to use huge pages (2 or 4 MB) because those are > simply too large to scan in a reasonable amount of time. > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
