Fog Creek Software
Discussion Board




speaking of leaky..

that article on leaky abstractions got me thinking about a long time dislike i've harbored against virtual memory.

it seems to me that virtual memory is too leaky, for the benefits it provides.  by the time you're using it, your applications are running so poorly you might as well cry.

it also makes additional disk traffic, which is bad for power consumption.

it seems to me that the primary reason that people use virtual memory is that they're worried about the can of worms that might be opened up if we subjected processes to out of memory errors again.  (like the mac of the mid nineties did)  consider that virtual memory doesn't provide applications limitless memory, it just assures that they run slowly enough that they'll never reach that limit.  if so, VM is nothing more than a disguised doomsday device.
so if VM doesn't actually do what we're keeping it around for, why not jettison it?

screw page files. blech

agree? disagree? don't care?

nate
Friday, November 22, 2002

"virtual memory doesn't provide applications limitless memory, it just assures that they run slowly enough that they'll never reach that limit"--nate

This is going in my 'Great Quotes of CS" file. Thanks.

X. J. Scott
Saturday, November 23, 2002

Actually, I think you have a misconception about what virtual memory does.

Think of it as a cache for code pages. the OS can swap code pages that haven't been used for a while out to the disk, making more real memory available for applications to use.

When one of the pages that has been swapped out gets hit, a page fault occurs, and the OS loads the memory for the app to use.

If the paging system is well tuned, you'll rarely notice that pagine is occuring. 

The only time you'll get the behavior you are describing is when there is so much stuff going on that you are constantly hitting page faults and constantly swapping in memory.

The solution for this isn't to throw away virtual memory, its to simply choose between running fewer applications, or adding memory to your machine.

At today's prices, I'd recommend the latter...

Joe
Saturday, November 23, 2002

I'm having flashbacks to the alternatives - working with manually paging memory, segment registers, overlay managers... oy.

I'll gladly take virtual memory over THAT kind of stuff any day of the week.

Chris Tavares
Saturday, November 23, 2002

[  ]agree?
[X]disagree?
[  ]don't care?
[X]Thinks you don't understand how virtual memory works

Robert Moir
Saturday, November 23, 2002

[  ]agree?
[X]disagree?
[  ]don't care?
[X]Thinks you don't understand how virtual memory works

blinker
Saturday, November 23, 2002

actually, i think i understand how virtual memory works...

i'm not suggesting overlay managers,  hand paging, or any other non automatic memory management.  i'm suggesting that at some point in the last ten years we crossed a threshold from a memory-scarce world to a memory-abundant world, and that continuing to page to disk is an obsolete idea, because:

a) it is no longer neccessary (memory is abundant)

b) it degrades performance

nate
Saturday, November 23, 2002

[  ]Still agree?
[X]Still disagree?
[  ]Still don't care?
[X]Still thinks you don't understand how virtual memory works

SM
Saturday, November 23, 2002

Hello? Virtual Memory is an essential component of isolate process spaces.  Sure software would be faster if it all ran straight on the CPU, no processes no threads no paging. Course this would only work the program running my microwave. 

Not to mention my commit charge is generally over 700mb.
My system doesnt page to disk unless I commit more than my avail physmem, or its been a long time since that page was used.  If you really wanted on windows(nt+) you can disable your page file.  Enjoy running only 2 or 3 apps at time.

former VM developer
Saturday, November 23, 2002

[  ]agree?
[X]disagree?
[  ]don't care?
[X]Thinks you don't understand how virtual memory works

Carnage4Life
Saturday, November 23, 2002

If you're so worred about virtual memory on your own machine you can do one of two things.

a) disable it but run the risk of crashes, or even that some programs won't run

b) Set up a RAM disk and put the paging file on that

I may be ignorant but I thought that the OS only wrote to disk if Physical memory started getting short.

Stephen Jones
Saturday, November 23, 2002

"Hello? Virtual Memory is an essential component of isolate process spaces.  Sure software would be faster if it all ran straight on the CPU, no processes no threads no paging. Course this would only work the program running my microwave."

i'm not suggesting that we do away with virtual adress spaces.  just paging to disk.

"I may be ignorant but I thought that the OS only wrote to disk if Physical memory started getting short."

in an effort to keep physical memory available, windows writes pages to disk, even when physical memory is available.  that is, windows pages things out in anticipation of new pages to come.

"The solution for this isn't to throw away virtual memory, its to simply choose between running fewer applications, or adding memory to your machine."

i would do the latter, but it's not an option.

"[X]Still thinks you don't understand how virtual memory works"
yes, and i love you too.

virtual memory is a leaky abstraction.
it appears to lift memory constraints, but it does so at the cost of acute performance degradation. 

nate
Saturday, November 23, 2002

Hm.

It seems to me that nate is write and you other folks, though perhaps possessing a passing acquaintence with VM, are not as knowledgeable as you seem. I'm no expert, I had to implement a virtual memory manager as a class assignment my sophomore year and evaluate various paging algorithms. It worked OK but I didn't enjoy it.

Former VM Developer in particular seems unaware that virtual memory and virtual addressing are two different things. Both are often assisted by the hardware memory management unit. But they don't even always go together - turn off pageing to disk and you have virtual addressing but not virtual memory. Or fire up a Classic OS Mac and you have virtual memory but not virtual addressing. VM developer, are you a VLSI developer or what?

VM does simplify programming if you can assume infinite memory and not have to deal with going to disk explicitly when dealing with enormous data sets. And VA definitely makes for a more stable OS (at a very unnoticeable speed cost with a MMU). But there is not doubt that the system bogs down when it starts paging and thus the abstraction leaks.

nate rules. You others need to stop a-talkin' trash on him and spend more time studying and less time flaming.

X. J. Scott
Saturday, November 23, 2002

One more comment.

The thing about how infinite memory reduces bugs since all functions can safely assume that memory allocation succeeded seems like sloppy programming to me. You should at least try to be able to recover from out of memory errors right? Or have practices changed so much that error conditions are not trapped and handled anymore?

X. J. Scott
Saturday, November 23, 2002

"You should at least try to be able to recover from out of memory errors right? Or have practices changed so much that error conditions are not trapped and handled anymore? "

Now you mention it, it's been years since the last time I saw malloc() fail...

Leonardo Herrera
Saturday, November 23, 2002

Excellant! Now we're getting on to an interesting topic.

Should we even bother trying to recover from memory allocation failures anymore?

Exceptions are messy for example. And code I see that uses exceptions is mainly dealing with side effects of memory allocation failure. Should we even bother? Should we just strip out all that messy exception handling code and fly by the seat of our pants, relying on paging to catch us should we ever fall?

X. J. Scott
Saturday, November 23, 2002

Should we even bother?  Yes and no.  Try to recover as though nothing happened?  Probably/usually not.  In my experience this does more harm than good.

Try to exit as gracefully as possible, do as little damage as possible, leave a log trail as detailed as realisticly possible - yup, do that.  Either some human or perhaps even another process is going to do some forensic analysis and want to know what happened so they can fix it.

Nat Ersoz
Sunday, November 24, 2002

Here's the thing: At least on Linux, malloc() uses an optimistic model: It assumes it will succeed and gives you the memory when you first try to write to it.

Meaning malloc() ALWAYS works. What happens in this case? Er, what should you do? You're program is simply guarenteed to crash when an OOM condition occurs, because it cannot be detected. How should/can software handle that?

I have OOM traps anyway, but I've been thinking for a while about that. I don't know.

Mike Swieton
Sunday, November 24, 2002

Once you guys start writing real programs and not assignments you will find that virtual memory is still very much in demand. 

I'm watching my server swap to disk right now
Sunday, November 24, 2002

One thing that virtual paging systems allow that is actually really useful is memory-mapped files.  By mapping a file on disk to a region in the virtual memory space, you can often read data out of files much more efficiently than by using the standard stream based models.  Writing to a mapped file also gives some advantages, at least in situations where you're updating items in the file, rather than extending the size of the file.

Ben Combee
Sunday, November 24, 2002

Re: Linux VM

[root@psyche root]# cat test.c
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv) {
        char *x;
        size_t y = 800 * 1024 * 1024;

        printf("allocating %u bytes\n", y);
        x = malloc(y);
        if (x == NULL) {
                printf("Oh no, I ran out of VM!\n");
        }

        return 0;
}


[root@psyche root]# echo 0 > /proc/sys/vm/overcommit_memory
[root@psyche root]# ./test
allocating 838860800 bytes
Oh no, I ran out of VM!
[root@psyche root]# echo 1 > /proc/sys/vm/overcommit_memory
[root@psyche root]# ./test
allocating 838860800 bytes

Just FYI.

Omar Kilani
Monday, November 25, 2002

You will get <a href="http://www.amazon.com/exec/obidos/tg/detail/-/0471417432/qid=1038216119/sr=8-1/ref=sr_8_1/102-3771676-7844925?v=glance&s=books&n=507846">this</a> book, and then you will understand the point of VM.

Basically, your complaint is that if a program's working set is larger than total userspace memory, VM is pointless.  This is entirely accurate, but misses the point: VM isn't a solution to memory management for a single program; it's a solution to memory management for multiple programs.

Jason McCullough
Monday, November 25, 2002

How about some wires from the client to your brain, that way we can utilise some of the 90% of our brain box that we don't use - i.e virtual memory.

640 should be enough
Monday, November 25, 2002

Nate,

You don't play any modern games, do you?

Malachi
Wednesday, December 04, 2002

is this thread still alive?

malachai, what about modern games?

jason mccullough, i think you raise a good point about VM not being a good solution for single programs, but a good solution for multiple programs.

i forget exactly what made me so pissy about VM to begin with.  i was probably trying to task switch out of icewind dale or something, and my computer croaked.  mostly i'm just perturbed at watching inefficiency grow exponentially along with memory resources.  this is not to say that inefficiency doesn't have its rightful place.  who among us would honestly say its worth the pain in the butt to program a gui in assembler for the added efficiency.  not me anyways.

whateverishly,
-nmr

nate
Friday, March 07, 2003

*  Recent Topics

*  Fog Creek Home