On 25 February 2010 04:30, William Leslie <[email protected]> wrote: > On 25 February 2010 11:33, Ben Kloosterman <[email protected]> wrote: >> I would say the developer is better of deciding what goes into >> memory as it matches the logic flow than the paging mechanism ,
Have you looked at the papers linked at the beginning of the thread? They explore ways to make the paging mechanism match the workflows of different applications. >> especially these days with GC and most of the memory being media >> especially with LRU being almost useless these days ( due to user app >> GCs walking pages or caches where the least recently used page is the >> prime candidate for next use) . Look at DOS where apps much larger >> than main memory were supported by the developer if it ran paging >> these apps would have been unusable. How so? They were only supported by each application developer implementing their paging. If there was paging already inplace there would be no need for that (and indeed many applications would use the same paging library). > > 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? Thanks Michal ------------------------------------------------------------------------------ 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
