| |||||||||||||
|
| |||||||||||||
Short topics in memory managementShort topics in memory managementPosted Mar 7, 2007 11:28 UTC (Wed) by njs (subscriber, #40338)In reply to: Short topics in memory management by k8to Parent article: Short topics in memory management
The cache's he's referring to in the firefox case are explicitly the in-memory ones -- while in principle an app could write such caches out to disk and trust the OS to make accessing that data as efficient as reasonable, in practice this may require major restructuring of your app. Firefox *does* cache pages on disk, of course, but it also has a smaller in-memory cache of fully parsed and rendered pages; the point of this is to avoid the re-rendering (and re-executing javascript, etc.) overhead of going to the normal disk cache (which just stores html files), and there's no reasonable way to take giant in-memory object graphs and write them do disk directly.
Now OTOH one would hope Linux would be clever about reclaiming memory by writing such memory out to swap... though various things could thwart this, e.g., if Firefox has a garbage collector tromping over those pages and keeping them resident, or if its memory is sufficiently fragmented that objects that are just being kept around as a cache, and objects that are in active use, happen to share pages.
These are just potential problems, though; I have no idea if they come up in practice. The firefox I'm typing this in seems to be about 300 megabytes total, but about 100 of those have been pushed out to swap, even during active use on a lightly loaded system without much memory pressure. Now, of course, it might be that those 100 megabytes are unused because they were actually leaked or something, but it is at least suggest that the "firefox problem" is not as bad as the original poster thinks.
(Log in to post comments)
|
|
||||||||||||