To clarify , my view is that paging to disk is bad to have as a compulsory feature as it strongly limits the platforms your OS runs on ( I prefer it as optional , and in my case I turn it off as I prefer out of memory messages to death by paging and lower power use by spinning down the disk).
With regard to paging ie Virtual Memory with pages it provides a cheap write barrier , now for an OS which does not limit the runtime it is almost compulsory. For a language based OS that compiles from an IR like Singularity/MOSA you are better of integrating such write barriers into the GC code and even skip Virtual memory and the associated TLB flushes. Regards, Ben >-----Original Message----- >From: William Leslie [mailto:[email protected]] >Sent: Friday, February 26, 2010 9:21 AM >To: CapROS development >Subject: Re: [CapROS-devel] Paging and Garbage Collection > >On 25 February 2010 19:20, Michal Suchanek <[email protected]> wrote: >> On 25 February 2010 04:30, William Leslie ><[email protected]> wrote: >>> Letting the application developer decide the paging strategy makes >>> memory pressure a more useful covert channel, though. It could be >less >>> of a big deal now that applications are moving to safe languages, >>> indeed, it may be reasonable to allow application specific paging >>> algorithms working in an environment where side effects from the >>> frequency of paging are provably impossible. >> >> You can't force the application to run in a safe language, can you? > >I meant the pager, but I was wrong anyway. As long as the pager >implements the eviction strategy, and not the process of populating >the pages, this is safe. But if you want to, for example, use memory >as a cache but generate its contents on page in, or implement an >application or language specific serialisation and persistence >strategy, that is a different kettle of fish. > >On 26 February 2010 04:35, Jonathan S. Shapiro <[email protected]> wrote: >> On Wed, Feb 24, 2010 at 7:30 PM, William Leslie >> <[email protected]> wrote: >>> >>> Letting the application developer decide the paging strategy makes >>> memory pressure a more useful covert channel, though. >> >> >> Not correct. What creates the channel is allowing the memory pressure >of one >> application to have impact on the paging behavior of a second >application. >> If this is sufficiently isolated, there is no further hazard from >allowing >> the application to make its own eviction choice. > >Sure, but a fixed allocation could be prohibitively expensive as a >default in a general purpose system. You want to use the ram you have. >Giving each user, let alone each eg browser process their own >dedicated spacebank does not seem reasonable, and neither does >requiring the user to set allocations. > >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 ------------------------------------------------------------------------------ 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
