4 ms·
Ah, that makes things clearer - thanks. > What I'd like to know is how you can guarantee that all garbage is eventually collected in a system like this. Me to
by vsingh 16y ago
Ah, that makes things clearer - thanks.
> What I'd like to know is how you can guarantee that all garbage is eventually collected in a system like this.
Me too. If you can't guarantee that, it seems that when you unmap a page of virtual memory, you'd have to make sure never to use that page again. You'd also have to keep around your table of "mappings from old pointers to new pointers" forever, just in case you encounter a lingering bad pointer and need to correct it.
- modeless 16y agoYes, exactly, in fact I was just editing my post to add that concern! Their garbage collector constantly scans the heap fixing up pointers so you don't have to wait for every reference to hit a page fault, but it seems difficult to guarantee that you're done if the program is twiddling references while the collector is doing its work. Perhaps there is also a write barrier which makes sure to never write a pointer to a collected page.
- pdubroy 16y agoYou're probably right. Although he doesn't mention the write barrier, this is usually required for a generation GC.
- runT1ME 16y agoMost Generational GC's (including Hotspots, which is the origin of Azul's JVM) will have the JIT insert a write barriers for all pointer sets. This is to keep track of cross generational references (so you don't have to scan the entire heap). The hard part has always been dealing with reads, (which are much more common and expensive to put a software barrier around), and Azul has quite brilliantly figured a way to handle this both in their specialized hardware, and now their VM.
- pdubroy 16y agoI think the trick is that after you complete the next mark phase, you have visited every possible pointer to the unmapped page.
- modeless 16y agoOnly if the program hasn't written a new reference to the unmapped page in that time. You need to check on writes too.