Hi William , The original post did not state whether it was the system object GC or application GCs , I took it ( probably wrongly) as any GC. Since page faults in application GCs are a major issue to the point that OS no longer rely significantly on LRU based mechanisms then I would say your paging code must meet the needs of your applications first, now if paging is not based on LRU how do you use it or will there be different paging code for the system pages?
>> 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. As for a can of worms I will raise you one :-) Is this a good architectural assumption for the future ? I know Eros and its descendents were based on disk first storage for security but I'm seeing a lot of newer devices with no or very little local storage with the OS loaded from some sort of ROM or where any storage takes away from memory making any form of paging counterproductive. This covers diskless workstations/thin client terminal, phones etc which may use the internet for storage and have a strong security requirement. Is paging an unnecessary anachronism with new 32 bit systems having no or little secondary storage and few 64 bit systems need it esp after windows apps ? We can still achieve Orthogonal persistence to slower internet based storage just saying paging may not be the best method as it makes some key assumptions about the form of secondary storage. Thats my 2cs worth. Regards, Ben >Subject: Re: [CapROS-devel] Paging and Garbage Collection > >Disclaimer: I don't really know if this can of worms is worth opening >yet. > >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. > ------------------------------------------------------------------------------ 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
