Disclaimer: I don't really know if this can of worms is worth opening yet. Garbage collection on orthogonally persistent operating systems draws some parallels with generational mark and sweep collectors on paged heaps, but also several differences. For example, since the system GC can operate below the abstraction boundary of virtual memory, it can avoid paging in if it knows what pages are clean and what references into the live heap they may contain. Neil's work covers this, and references much more on the subject.
Exactly how to avoid paging those objects in is the question. Searching the disk for references to an object when it is loaded or when a GC cycle begins is probably not reasonable, remember CapROS and Coyotos may be dealing with backing stores several Terabytes in size, and several of them. In a model where GC roots from outside core are cached, who pays for their allocation? Is it possible to bound the space (to less than half of the available cspace, thanks) taken by external roots in an EROS-style persistence system and still ensure progress? > 1. GC's will have artificially high ranking and steal pages and the OS has > no control over the variety of GCs produced at least Javascript , .NET and > Java are present on most Windows systems. Integration of application GCs with the GC of its spacebank is another topic, probably for another day. > Also why should there be many page faults in modern systems ? By the time an > OS designed now is released you are looking at either mobile phone systems ( > or smaller) with no swap space or 8 Gig 8 core machines, in either case a > new OS should have few bloated apps should have plenty of memory. The change in references into memory from the disk should stay small *except* when an object is paged in, we know nothing about what may reference it in that case, so what you say may only be true for objects that have never not been in memory. I don't think CapROS tracks that state at the moment, a page has either been checkpointed or it hasn't, but I don't think 'never paged out' is a good way to delimit a heap of potentially significant size, anyway. Finding ways to delimit a heap is where all the work lies. William Leslie ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ CapROS-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/capros-devel
