There are obvious advantages to VM, but could it be that nearly all of us have learned to program in an environment where VM was a given, and we haven't yet thought of computing models which could be better (in at least some aspects)?
While I think there are some serious data structure issues without VM, shared memory is one of the areas that becomes *much* simpler. Provided that the OS/MMU allowed access to the block, all reads and writes would be programmed to the shared segment (modulo any required semaphores) just like any private block.
Ignore for a moment the difficult task of rethinking data structures and user level memory management in an non VM environment (and rethinking everything we've all learned about modern day programming).
What if the moral equivalent of the fork () and exec() system calls loaded a program into a block of physical memory chosen by the OS, and all references to other instructions throughout the code (think of every branch) were modified at the time of the "load" to replace offset addressing with the correct physical address?
You could now have a program that could run without an MMU of the form we currently have (we'd still need some form of process protection, to control which processes could read/write where, enable and disable shared physical blocks of memory, etc), would never have a TLB miss, and would only pay the cost of address translation once for each line of code.
Processes might just be resident in memory in their raw state (the equivalent of storage on today's filesystems), and as instantiated running processes with data and a modified set of instructions based on where the process was loaded into physical memory.
The same could be true of variables and static arrays - which could have addresses translated to physical addresses once, and only once. Yeah - I know that static arrays are probably the kinds of things that make today's college graduates either squirm (thinking that it is as 'evil' as using a goto), or wonder "what is a static array?", but there was a time when people cared about raw performance, were a lot closer to the underlying hardware (if for no other reason then we didn't have MMUs on PCs back then), and did some truly amazing things (Zaxon on my Apply IIe used no more than 1/53rd as much memory as Microsoft's calc.exe just used to perform this calculation)... and those folks used lots of static arrays.
I admit that I have a hard time thinking how modern day computing would work in a non VM environment, but with the original impetus for VM coming to a close at some point (main memory equal in size and speed to hard drive capacity), I think it is worth rethinking some of our fundamental assumptions about CPUs, MMUs, operating systems and programming models.
The "free" in the post above isn't really free, and I just wonder if we can offload some of the headache of memory management from the OS/MMU into the compiler and discreet phases of process creation, getting a performance increase.
Beyond the obvious potential benefits of tossing out a mechanical device from a computer (power, speed, reliability, weight)... if all of our storage is basically running at the same fast speed, would there be any need for VM anymore?
Perhaps we could just fragment the memory system into parts which could be used by the operating system, vs. those for user space, with appropriate protection mechanisms placed by each process on it's allocated (but physically addressed) space.
There are plenty of 'advantages' to using VM, but each layer of goo we put on top of the underlying hardware causes a performance penalty (both because of the extra layer of indirection, and the abstractions taught in school make it almost a sure thing that kids today will write really inefficient software).
We'd need to keep processes which weren't supposed to write all over each other from doing so with a new form of protection... Maybe it's just that I miss poke and peek, but I think I'd be happy to ditch VM as we know it along with the spinning platter.
Slashdot Mirror
There are obvious advantages to VM, but could it be that nearly all of us have learned to program in an environment where VM was a given, and we haven't yet thought of computing models which could be better (in at least some aspects)?
While I think there are some serious data structure issues without VM, shared memory is one of the areas that becomes *much* simpler. Provided that the OS/MMU allowed access to the block, all reads and writes would be programmed to the shared segment (modulo any required semaphores) just like any private block.
Ignore for a moment the difficult task of rethinking data structures and user level memory management in an non VM environment (and rethinking everything we've all learned about modern day programming).
What if the moral equivalent of the fork () and exec() system calls loaded a program into a block of physical memory chosen by the OS, and all references to other instructions throughout the code (think of every branch) were modified at the time of the "load" to replace offset addressing with the correct physical address?
You could now have a program that could run without an MMU of the form we currently have (we'd still need some form of process protection, to control which processes could read/write where, enable and disable shared physical blocks of memory, etc), would never have a TLB miss, and would only pay the cost of address translation once for each line of code.
Processes might just be resident in memory in their raw state (the equivalent of storage on today's filesystems), and as instantiated running processes with data and a modified set of instructions based on where the process was loaded into physical memory.
The same could be true of variables and static arrays - which could have addresses translated to physical addresses once, and only once. Yeah - I know that static arrays are probably the kinds of things that make today's college graduates either squirm (thinking that it is as 'evil' as using a goto), or wonder "what is a static array?", but there was a time when people cared about raw performance, were a lot closer to the underlying hardware (if for no other reason then we didn't have MMUs on PCs back then), and did some truly amazing things (Zaxon on my Apply IIe used no more than 1/53rd as much memory as Microsoft's calc.exe just used to perform this calculation)... and those folks used lots of static arrays.
I admit that I have a hard time thinking how modern day computing would work in a non VM environment, but with the original impetus for VM coming to a close at some point (main memory equal in size and speed to hard drive capacity), I think it is worth rethinking some of our fundamental assumptions about CPUs, MMUs, operating systems and programming models.
The "free" in the post above isn't really free, and I just wonder if we can offload some of the headache of memory management from the OS/MMU into the compiler and discreet phases of process creation, getting a performance increase.
Beyond the obvious potential benefits of tossing out a mechanical device from a computer (power, speed, reliability, weight)... if all of our storage is basically running at the same fast speed, would there be any need for VM anymore? Perhaps we could just fragment the memory system into parts which could be used by the operating system, vs. those for user space, with appropriate protection mechanisms placed by each process on it's allocated (but physically addressed) space. There are plenty of 'advantages' to using VM, but each layer of goo we put on top of the underlying hardware causes a performance penalty (both because of the extra layer of indirection, and the abstractions taught in school make it almost a sure thing that kids today will write really inefficient software). We'd need to keep processes which weren't supposed to write all over each other from doing so with a new form of protection... Maybe it's just that I miss poke and peek, but I think I'd be happy to ditch VM as we know it along with the spinning platter.