Re: Memory fragmentation?

Jean-Marc Desperrier wrote:

> You know if this is not a problem, if "disk space is dirt cheap" means 
> it's perfectly efficient to use huge amount of swap

No, and that's a terrible strawman argument. Swap *is* normally a 
concern, because if there's memory pressure the OS will be paging that 
data in and out (which kills performance). But here we're talking about 
a page completely unused by the app, which means it would never get 
paged in again. So other than occupying some disk space, it should be 
harmless [I suppose there would be a 1 time penalty when/if the OS 
initially pages it out, though.]

The problem is largely mooted by fixing the root problem (heap 
fragmentation), so that there are not typically large numbers of unused 
pages sitting around in memory or on disk.

> And VM system are *never* dealing with a single contiguous, homogeneous 
> block of memory. They are constantly trying to guess which memory page
> you application has stopped using to give it to another application. 

No, I'm talking about virtual memory, not real memory.

My assumption here was that the VM system can more efficiently deal with 
large contiguous regions of a process's address space than when it's 
scattered with unmapped holes. To me, "I'm using 0x10000000 to 
0x20000000" implies simple (fast) accounting, while adding hundreds or 
thousands of gaps to that would increase overhead.

Maybe there are clever techniques used to mitigate that... Which is why 
I just said I'm wary about doing this. Performance problems like this 
have a tendency to be fickle and require testing for conclusive answers.

Justin