Date: | August 9, 2004 / year-entry #302 |
Tags: | other |
Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20040809-00/?p=38213 |
Comments: | 10 |
Summary: | Virtual memory is not virtual address space (part 1). I don't know where this myth comes from; it's a non sequitur. Virtual address space describes how addresses are resolved, but since each process has its own virtual address space, the amount consumed by one program has no effect on that consumed by another program. Say... |
Virtual memory is not virtual address space (part 1). I don't know where this myth comes from; it's a non sequitur. Virtual address space describes how addresses are resolved, but since each process has its own virtual address space, the amount consumed by one program has no effect on that consumed by another program. Say you have a program that allocates 1GB of memory. Run three copies of it. Now you have a total of 3GB of allocated memory. And none of the programs came even close to exhausting its 2GB virtual address space allotment. Tomorrow, the debunking of a variation on this myth. |
Comments (10)
Comments are closed. |
As a side note, with a bit of work, you can use lots more than 2GB of memory per process without using /3GB: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/base/address_windowing_extensions.asp
This comes without the cost of throttling the kernel address space.
…but with the cost of being a royal PIA. It’s basically doing your memory management manually, with the side effect of also removing some physical memory permanently from the OS’s control – it can’t swap memory reserved for AWE out, allocate it to another process or use it for the OS’s own purposes.
Also, only users (security principals) with the ‘Lock Pages In Memory’ privilege (SE_LOCK_MEMORY_NAME) can call the AWE APIs. By default no principals have this right. SQL Server 2000’s setup program enables this right for the SQL Server service account. By contrast, the larger address space enabled by /3GB is available to all users.
SQL 2005 I think continues to support AWE on 32-bit x86 processors. The APIs are present but basically useless on 64-bit systems.
Does AWE work like late 80s memory managers with all that segment dance?
One such confused site is LockerGnome. Just goes to show that, as usual, you can only trust people that actually work in the field; not those that merely write about it :-)
(For a recently posted version of this myth, see http://channels.lockergnome.com/it/archives/20040806_when_is_4gb_of_ram_not_really_4gb_of_ram.phtml )
One should read "The Thing King" story and make sure it’s understood before commenting on modern operating system memory management.
I don’t see anything wrong with the lockergnome article except 1 skoppy use of a term (RAM) that everybody misuses anyway to mean any memory. I had to read it three times to find that anyway.
What about Shared Memory, Is some share of address Space reserved for it?
Shared memory is not shared address space. A little experimentation with MapViewOfFile will demonstrate.
Just picking a little nit about naming things…
Quote: "Myth: Without /3GB the total amount of memory that can be allocated across all *programs* is 2GB". Shouldn’t that be "… across all *processes* …" ?
Though I haven’t used the feature myself in this form, the .NET framework supports running multiple ‘programs’ within one single process, by running each of them in an AppDomain, isn’t it? I assume all of these ‘programs’ share the same virtual address space, so the 2G or 3G limit applies to the bunch of them together. In other words, running three instances of a WebApp, each of which take 1Gbyte, will cause your webserver process to run out of memory, isn’t it?
Though not the most common use of the word ‘program’ today, I can envision that soon you will need to clarify what you mean when using the word ‘program’; did you mean ‘process’ or did you mean ‘application’.
As Evan already mentioned on his blog, Raymond Chen has a great series on /3GB switch on his blog. What is really cool is that Raymond takes on some myths about the /3GB switch and the fact that he…