Solved Do you really need Virtual Memory?

[crawfish]

Sorry, but I don't consider shutting down like that to be "graceful".

Shutting down like "what"?

For instance, you may lose your current document because memory is in an unstable state.

Yes, that would indeed be ungraceful. I don't condone bad design that is prone to losing data.

You may not be able to open a file save dialog, or even write a dump file to disk.

That's true. If you want to do things that require resources when you have run out of resources, you need to plan for it instead of expecting to be able to acquire those resources when the time comes.

You can't really put a try/catch around everything that could possibly allocate some memory. It would make your code virtually unreadable, and difficult to maintain.

From a C++ perspective, if you are writing try/catch on a regular basis, you probably are making poor use of RAII, and you might as well be using return codes. Lots of try/catch clauses in a C++ program is a red flag of cluelessness until proven otherwise.

And exiting with an unhandled exception is hardly graceful, even if it does clean up after itself as much as it can...

For an exception occurring in a typical Windows program, you would end up at the top of your message loop, and there would be an attempt to notify the user of the problem, say, with a MessageBox. That would be the most basic response. For a C++ program, if you have made effective use of RAII, the program will be in a well-defined state, and there's a good chance you will not have written a single try/catch.

When I said, "For some programs, terminating immediately might be an acceptable "graceful" response," I was thinking of programs that aren't modifying persistent data. I wasn't saying this was appropriate for all programs.

Basically, most experts say it's fruitless to check most memory allocations. Yes, large allocations can be beneficial, such as knowing if you can load a large bitmap into memory... but that kind of memory failure is different from a memory exhaustion situation.

But if your position is that it's fruitless to check because you can't do anything about it, then you should terminate right away.

When a memory allocation fails, something is going to happen afterwards. You can (a) anticipate, detect, and deal with it in various ways, (b) detect it and terminate right away, or (c) ignore it and stumble along as if nothing happened until you finally crash somewhere down the line, maybe corrupting something along the way that wouldn't have happened if you had done (a) or (b). It seems to me you're arguing for (c), because you've said (a) is impossible, (b) is "ungraceful", and I don't see what else is left but (c).

 

[Pyanfar]

I've been dealing with various aspects of the paging/SSD/etc. lately, and the posts on this thread are some of the smartest statements I've seen on the subject. Just to add in my two cents' worth, I posted these thoughts recently at Overclock.net and I'll share them with you here...this was a discussion of paging, RAM disks, paging to a RAM disk, and deleting the paging file altogether (which is our OP's topic here).

I have played with this exact issue recently, just to see what it would do. I've got a system with 32GB of RAM and an SSD with plenty of space, and I not only didn't see any performance changes, I did see more obnoxious behavior, like Windows nagging me that it wanted 1.5X my RAM as its page file (but not actually using the thing) or trying to create temporary paging files after I disabled them.

In the end, I let Windows manage page file size because:

a) we're far from the days when the act of growing/shrinking the page file would take place often enough to cause a noticeable performance hit
b) Windows tends to be pessimistically greedy and make a huge page file that ...
c) ...it almost never uses when you have a lot of RAM. Really, it almost seems like the only reason for the Page file is backwards compatibility, and the throughput of an SSD is close enough to RAM that those occasional paging needs aren't going to be slowed enough to justify taking RAM away from the job RAM is expected to do in Windows: be there for the CPU when it's trying to run something.

I didn't get down in the weeds with the benchmarks because the simpler evaluations, such as 3DMark, manually watching processes, or even the re-running the WEI, didn't change performance one whit. All I noticed was the startup music (when login screen pops up) would stutter if I had no page file.

Hope that's useful to other people looking over this discussion--I just joined because of this thread, thanks.

 

[LMiller7]

In the end, I let Windows manage page file size because:

a) we're far from the days when the act of growing/shrinking the page file would take place often enough to cause a noticeable performance hit
b) Windows tends to be pessimistically greedy and make a huge page file that ...
c) ...it almost never uses when you have a lot of RAM. Really, it almost seems like the only reason for the Page file is backwards compatibility, and the throughput of an SSD is close enough to RAM that those occasional paging needs aren't going to be slowed enough to justify taking RAM away from the job RAM is expected to do in Windows: be there for the CPU when it's trying to run something.

Just a couple of comments:

a)

Under normal circumstances there will be zero impact from resizing the pagefile because it doesn't happen. By default the NT platform has always used a sem-fixed pagefile. The pagefile has configured initial and maximum values. The commit limit (as shown in Task Manager) is the sum of pagefile size plus RAM size minus a small overhead. If the commit charge never reaches the commit limit the pagefile will NEVER be resized. If the commit charge reaches the limit the pagefile will resize upwards by a multiple of some increment to meet the demand. On XP I once found this increment to be 16 MB. The idea being to minimize resize events. If at some later time the added portion of the pagefile is no longer needed it will be resized downward after a short delay. Again to minimize resizing. The maximum size configuration is just to prevent something like a runaway memory leak from forcing a pagefile taking up the entire disk space.

It is important to understand that this resizing will not occur under normal conditions. It is essentially an emergency measure to prevent exceeding the commit limit which could have dire results for an application or even the system. The idea being to have an initial size for the pagefile so that this resizing will never be needed.

When the pagefile is system managed the system will set the initial and maximum sizes of the pagefile - nothing more. It does not mean the pagefile will continuously resize according to need.

b)

It has often been said that setting the initial pagefile size according to RAM size is a ridiculous idea. With more RAM the pagefile should be smaller, not larger. But there is a good reason for this.

When Windows is installed it has no idea what your workload will be. But it has to set the pagefile initial size to something. So it makes a guess, assuming the workload will be comparable to RAM size. With a heavy workload a large pagefile will be necessary to make optimum use of RAM. Of course if you have 16 GB or mare RAM and have a light workload then most of the pagefile will not be used. But the only harm in this is wasted disk space. It will not encourage excessive use of the pagefile. The idea being to maximize performance, not minimize disk usage.

 

[Pyanfar]

Great explanations LMiller7! I'm glad to run across someone who went to the trouble to monitor the resize thresholds: I never knew that about XP.

Back in the earliest days of Virtual Memory (Windows 95?), the disk activity was more of a problem--but hey, that was a very different set of hardware from today...I think your clarification (both points a and b) says it best.

The only other thing I could probably add here is that another way I explain it to people sometimes is, "This isn't going to mean the system uses a massive page file all the time: it's more that Windows ropes off a section of hard drive, says, 'I'm going to work with this much space, and this much definitely belongs to me', and then proceeds to go on about its business of paging as much or as little as it needs." I had to go through this a bit when trying to tune some Windows Servers at my job and being asked about whether a 16GB server needed a 40GB page file (2.5X RAM).

 

[Luke Warm]

Well with 16 GB of Ram, try it. Then Open a Blue Ray Movie if you have one on disk, see what happens when you try to play it. Or, if you have a BR Player on your system. If the movie file is 30 GB or larger, will it load all of it into VLC or whatever Video Player you use? Or will it just load the Video and Audio as needed by the Program?

If you are running a program that LOADS a 30-GB file, it may choke on that without the Virtual Memory. But you can try it out and see what happens. I'd be eager to see how the system runs without Virtual Memory.

The video playing program buffers the video into memory in sections, it never loads the whole file at once.

Virtual memory is a memory management technique where a managed amount of hard drive disk space is set aside to only be used for one purpose. This space is called a “paging file”, and this technique’s intent is to map and address this part of that drive in the same way as memory is; the “paging file” can then be used like, and treated as, memory. If your computer is loading a program, and it does not have enough space in the Physical Memory left to hold the files that the CPU needs to use to run that program, the computer will put the lower priority files in the memory addresses located in the “paging file”. It having to be used for this purpose is bad news because, a hard drive’s read and write speeds (100 MB/s) are very slow when compared to Physical Memory’s speed (12800 MB/s). An insufficient amount of physical memory will hurt your computers performance; when the paging file has to be used as a memory to run a program, depending on the extent of usage, it can cause the computer to slow way down.

There is normally several GBs of hard drive space reserved for Virtual Memory’s exclusive use; this is not a frivolous system, I say this because this “paging file” is used for a lot more purposes than just a memory overflow. Even if you have more than enough physical memory, Microsoft says “do not turn the paging file off, or adjust the values low”. Some programs use this “paging file”, and will not run if it is turned off. One of the big reasons they use it is because data permanently stays there until it is moved; unlike physical memory where if the system loses power, all data is lost. For that same reason, this also makes the paging file ideal for use by operating system to back-up the physical memory in case of a power failure or catastrophic system error. Even though the amount of disk space that is reserved for Virtual Memory is adjustable, unless you receive warnings that your virtual memory is low, I strongly recommend that you let Windows automatically manage this system as I do.

The only reason I would turn the size allocation down is, there is an insufficient amount of space in the operating system's partition. But this is not a fix, it is a band-aid; I would instead install the OS on a larger partition. The only reason I would turn it off is, if the computer is being used for a dedicated purpose where the presents of a paging file will degrade the systems performance; it is very rare for a computer to be used like this.

 

[XweAponX]

The video playing program buffers the video into memory in sections, it never loads the whole file at once.

Yah, I realise that now, I didn't when I made that comment.

 

[LMiller7]

Microsoft has long described the pagefile as "A paging file is an area on the hard disk that Windows uses as if it were RAM". Unfortunately that is a very crude description and calling it misleading is giving it more credit than it is due. Many Internet articles and forum posts have attempted to elaborate on that description and have only served to further confuse the issue. It is a part of the old problem of how to describe complex technology in a way that is both technically accurate and yet easy to understand. Sometimes it is done well, but often it is not.

The pagefile is not some kind of overflow area that is only used when RAM runs short. That was never a part of the design of the Windows pagefile, at least not for any version released in the last 20 years. The pagefile was designed as a performance optimization and it usually works.

After a system has been up for some time there will be a substantial amount of RAM used to store data that has not been recently accessed and in some case may never be accessed again. That is a serious misuse of high performance RAM and a crime against performance. And Windows is well aware of where that memory is.

The pagefile was designed as a solution to that problem. Windows memory manager offloads that old and stale data to the pagefile where it belongs and frees the RAM used to contain it for more useful purposes. That might be for an active application or as part of the system cache. The pagefileis certainly slower than RAM but if the data it contains isn't used often it really doesn't matter much. If the data does have to be read from the pagefile it will be copied to RAM. If the data is worthy of being kept in RAM it will stay there.

Applications never access the pagefile themselves. Any attempt to even read from the pagefile will fail. Reading and writing of the pagefile is the exclusive domain of the system memory manager. Applications do use pagefile backed memory but when or if the data is ever written to the pagefile is entirely up to the memory manager, not the application.

Pagefile use has numerous performance optimizations to ensure that it's use will have the smallest possible negative impact on performance and that overall it will be a net benefit to performance.

The big problem with disabling the pagefile is that it imposes a hard limit on the commit limit. I will not attempt to describe what it is but be assured that hitting that limit is not a pleasant thing. Some applications handle that reasonably well but others do not. In many cases the application fails with often dire consequences for any unsaved work you may have. With default pagefile configuration not only is the limit much higher but it can be raised even higher if the need arises. Hitting the limit is then a rare occurrence.

 

[TairikuOkami]

Well, everyone is talking about compatibility, but disabling pagefile also increases security a bit.Viruses like to reside in it and of course removed documents, even previously encrypted could be restored from it.

The big problem with disabling the pagefile is that it imposes a hard limit on the commit limit. I will not attempt to describe what it is but be assured that hitting that limit is not a pleasant thing. Some applications handle that reasonably well but others do not. In many cases the application fails with often dire consequences for any unsaved work you may have. With default pagefile configuration not only is the limit much higher but it can be raised even higher if the need arises. Hitting the limit is then a rare occurrence.

It really depends on a user, an amount of RAM and of course running applications, like Adobe or games. I am quite happy with my setup, Windows takes only 500MB RAM, basic commit limit is about 600MB, max 3GB.

 

[Luke Warm]

1. Microsoft has long described the pagefile as "A paging file is an area on the hard disk that Windows uses as if it were RAM". Unfortunately that is a very crude description and calling it misleading is giving it more credit than it is due. Many Internet articles and forum posts have attempted to elaborate on that description and have only served to further confuse the issue. It is a part of the old problem of how to describe complex technology in a way that is both technically accurate and yet easy to understand. Sometimes it is done well, but often it is not.
   
   The pagefile is not some kind of overflow area that is only used when RAM runs short. That was never a part of the design of the Windows pagefile, at least not for any version released in the last 20 years. The pagefile was designed as a performance optimization and it usually works.

   
   
   I know one of the people that wrote Windows XP, he said the paging file was there for many purposes, overflow was a big part of its original job. Memory was very expensive at one time, hard drive space was much cheaper than memory. I can remember upgrading from 64 MB to 256 MB, boy what a difference that made. The computer ran faster because the paging file did not have to be used as much. But I think you both are both talking about the same thing, moving lower priority files to the paging file to free up valuable memory space for higher priority use. It is similar to a warehouse manager managing product overflow to a less accessible back-up warehouse to optimize the space used in the main warehouse. Describing this complicated process as "overflow" is indeed a simplification, but for the sake of brevity, I believe that using this simpler name in future discussions is fare.
   
   

   After a system has been up for some time there will be a substantial amount of RAM used to store data that has not been recently accessed and in some case may never be accessed again. That is a serious misuse of high performance RAM and a crime against performance. And Windows is well aware of where that memory is.

   
   Each operating system has used the paging file slightly differently from its predecessor. If you give Windows 7 access to lots of memory, it will use it. Windows7 and vista includes a file caching mechanism called SuperFetch that caches the most frequently accessed application files in RAM so your applications will open more quickly. Windows 7 also uses the paging file to back up the memory more so than any other operating system before it. A Microsoft employee told me that "in Windows 8, because of SSD becoming more mainstream, it no longer caches often used programs. Windows 8 is more stream line". Windows traditionally, in the past, has managed memory poorly. Like the defrag tool, anti virus, fire walls, and memory management programs, Microsoft has seen the benefit of these programs and started using and improving them in their operating systems. None do a perfect job. Microsoft is always trying to improve and update their products. As technology changes, so must the programs that use it.
   
   
   

   The pagefile was designed as a solution to that problem. Windows memory manager offloads that old and stale data to the pagefile where it belongs and frees the RAM used to contain it for more useful purposes. That might be for an active application or as part of the system cache. The pagefileis certainly slower than RAM but if the data it contains isn't used often it really doesn't matter much. If the data does have to be read from the pagefile it will be copied to RAM. If the data is worthy of being kept in RAM, it will stay there.
   
   Applications never access the pagefile themselves. Any attempt to even read from the pagefile will fail. Reading and writing of the pagefile is the exclusive domain of the system memory manager. Applications do use pagefile backed memory but when or if the data is ever written to the pagefile is entirely up to the memory manager, not the application.

   
   
   This statement shows that you really don't know how a computer works. The programs and operating system are code, a configuration of orders and instructions. The program’s code sets file priorities and has operating instructions that Windows follows. Windows code, through the CPU, then controls the hardware. The memory manager is not a magical, self-aware piece of hardware, it does not set file priorities or make decisions; It, like all of the other hardware, only follows the instructions written in the code of the programs and operating system.
   
   Instruction path – program/windows/driver/firmware/hardware.
   The memory manager is hardware that is controlled by the operating system, but programs do exert an influence on the instructions that the operating system sends to the memory manager.
   
   

   The pagefile is certainly slower than RAM but if the data it contains isn't used often it really doesn't matter much.

   
   I disagree, you should not make a blanket statement like that; If your computer has plenty of memory, you are some what correct, but speed always matters. If you put 500 MB of memory in your computer with Windows 7, the slow speed will be more noticeable because mid to high priority files will be sent to the paging file a lot more frequently. The speed difference you will see depends on the amount of page file usage and the speed of the partition the paging file is in.
   
   

   Pagefile use has numerous performance optimizations to ensure that it's use will have the smallest possible negative impact on performance and that overall it will be a net benefit to performance.
   
   The big problem with disabling the pagefile is that it imposes a hard limit on the commit limit. I will not attempt to describe what it is but be assured that hitting that limit is not a pleasant thing. Some applications handle that reasonably well but others do not. In many cases the application fails with often dire consequences for any unsaved work you may have. With default pagefile configuration not only is the limit much higher but it can be raised even higher if the need arises. Hitting the limit is then a rare occurrence.

   
   
   The hard limit on the commit limit? In Windows 7, the Commit Limit is the sum of physical memory + Page File (roughly). All you are talking about is usage that exceeds the total available memory. The explanation that you gave does not address computers with more than enough physical memory. Also, physical memory overflow is not the paging file’s only purpose.
   
   The problem with disabling the paging file is:
   *** Windows and some of the programs we run, have paging file use written into them. The lack of a paging file is a problem that forces them to go to "plan B". If there is no "plan B" written for the need, or "plan B" is poorly written, the problem becomes severe. Computers are not smart, all they do is process code. This severe problem will cause a blue screen or "failure to respond". A blue screen is the result of an unrecoverable Windows error. A "failure to respond" happens when windows is trying to recover from an error, an unsuccessful attempt at the recovery often turns into a blue screen.
   *** The same scenario as above happens if the computer has plenty of physical memory, but the paging file is adjusted too small for the code's "plan A". If there is a poorly written or no "plan B", Windows will error.
   *** The presents of a paging file increases the amount of total available memory (the sum of physical memory + Page File), and decreases the probability of your computer ever having an insufficient amount of memory. Windows will error if it runs out of memory during an operation.
   *** The operations that use the pagingfile for back-up will no longer have this fail-safe, and the ones that use it for any other purposes will no longer be able to fulfill this need.

 

[Luke Warm]

Well, everyone is talking about compatibility, but disabling pagefile also increases security a bit.Viruses like to reside in it and of course removed documents, even previously encrypted could be restored from it.

The big problem with disabling the pagefile is that it imposes a hard limit on the commit limit. I will not attempt to describe what it is but be assured that hitting that limit is not a pleasant thing. Some applications handle that reasonably well but others do not. In many cases the application fails with often dire consequences for any unsaved work you may have. With default pagefile configuration not only is the limit much higher but it can be raised even higher if the need arises. Hitting the limit is then a rare occurrence.

It really depends on a user, an amount of RAM and of course running applications, like Adobe or games. I am quite happy with my setup, Windows takes only 500MB RAM, basic commit limit is about 600MB, max 3GB.

If you are worried about security (problem files left in the paging file system) there is a way to flush all of the memory at restart. Physical memory always flushes at restart, the paging file system only flushes if it is told to do so. There is a down side to doing this; Widows will lose some of its functionality, the page file can no longer be used as a memory back-up.

Start Registry Editor (Regedt32.exe).Change the data value of the ClearPageFileAtShutdown value in the following registry key to a value of 1:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
If the value does not exist, add the following value: Value Name: ClearPageFileAtShutdown
Value Type: REG_DWORD
Value: 1
Source: How to Clear the Windows Paging File at Shutdown

OR, if you don't want to play in the registry, here is another way.

Click Start Click Control Panel
Click Administrative Tools
Click Local Security Policy
Click the "+" next to Local Policies
Click Security Options
Doubleclick "Shutdown: Clear Virtual Memory Pagefile" Select the "Enabled" radio button
Source: Clear Your Page File

 

[LMiller7]

There is a down side to doing this; Widows will lose some of its functionality, the page file can no longer be used as a memory back-up.

I have no idea what that means.

The only downside to doing this is the time it takes, but on some systems that can be considerable. There will be no loss in functionality except for hibernation which requires an intact pagefile.

The setting forces the pagefile to be completely overwritten with zeros at system shutdown. This is a security measure only and has no other benefits. At startup Windows never uses the previous contents of the pagefile (except after a memory dump is created). Windows will not permit an application to access the pagefile for any purpose while Windows is running.

This setting can be useful but it really only makes sense as part of a comprehensive security policy. Most systems have security issues that are much more serious. Finding a password in the pagefile is quite easy - if you know what it is. Finding an unknown password in a pagefile will be enormously difficult.

This setting has been widely misrepresented on the Internet.

 

[Luke Warm]

There is a down side to doing this; Widows will lose some of its functionality, the page file can no longer be used as a memory back-up.

I have no idea what that means.

The only downside to doing this is the time it takes, but on some systems that can be considerable. There will be no loss in functionality except for hibernation which requires an intact pagefile.

The setting forces the pagefile to be completely overwritten with zeros at system shutdown. This is a security measure only and has no other benefits. At startup Windows never uses the previous contents of the pagefile (except after a memory dump is created). Windows will not permit an application to access the pagefile for any purpose while Windows is running.

This setting can be useful but it really only makes sense as part of a comprehensive security policy. Most systems have security issues that are much more serious. Finding a password in the pagefile is quite easy - if you know what it is. Finding an unknown password in a pagefile will be enormously difficult.

This setting has been widely misrepresented on the Internet.

I like you. You challenge me and make me think.
You know exactly what I mean,
but you do not believe that the pagefile is used for physical memory back-up,
and you do not think an application can access a pagefile.

You do not think an application can access a pagefile
The PageFile is not hardware; there is not a PageFile circuit or IC chip anywhere on the main board.
The PageFile is software. It is a subprogram that is part of Windows. The PageFile and the memory controller are controlled by windows code, though the CPU. The program’s code tells Windows what to do to run the program. It tells what files are needed to run each operation, it also tells Windows the priority for each file.There is no way for Windows to know this without being told by the program’s code.Most of the Memory management is done automatically by Windows using information that was obtained from the program’s code. If the program’s code gives specific instruction to windows pertaining to the memory controller or PageFile, Windows executes the code (follows instructions). An application cannot access a pagefile directly, but I am a programmer and I assure you that you are 100% wrong; applications do access the pagefile through Windows. A program can have Pagefile use written into it. A computer is not smart, everything it does, it is following code from software (applications and Windows).

Did you know that 4 core CPU usage has to be written into the operating system and the program’s code before all 4 cores can be used? The exact way all 4 cores are going to be used in every operation has to be written into the programs code, in a way the Windows understands. This means that Windows must have detailed usage code on how each core can be used, and the programmer of the application has to choose the appropriate code for that usage when it is needed. Windows XP had multi core usage written into it at midlife, it was poorly done. Visa is the first windows operating system that had multi core usage written into its core programing. Windows 7 and 8 are big improvements over Vista. More than 80 % of the programs are to simple for multi core usage to be written into there code. My point is, "code rules"; an application’s code can instruct Windows to do anything that complies with Widows code. You needed to understand this so that you will know how Windows must extensively interact with the program to run an operation. In the same way that the program (in order to be the most affective) has to tell Windows how to use the extra cores, Windows must also have the program's help (instructions) in order to be able to efficiently manage the memory. The friend that help write Windows XP, taught me most of what I know about programing (may he RIP). He was a Programing Engineer. The above spill about 4 core usage came directly from his mouth.


you do not believe that the pagefile is used for physical memory back-up
I have several Windows 7 computers, an Intel E8400 w/4 GB of memory, Intel QX9650 w/8GB of memory, Intel i7 2600K w/16 GB of memory. In every case, Windows manages the PageFile size, and the PageFile is the same size as the Physical memory. What in GODs green Earth would a PageFile do with 16 GB of hard drive space. With the Page file not losing its data at shut down, a back up would be an ideal use for this file. Windows 7 recovers better than any previous operating system after a power failure. If the used part of 16 GB of physical memory were backed up, this would make sense. The 16 GB pagefile is the most logical place.

I use Microsoft Word on a regular bases. If the page is not saved when the computer is turned off, Word shows you that page in a column on the left, and ask you if you want to save it. Since programs are ran from memory, the PageFile would be an easy place to cache that file, and it would still be there when Window is turn back on. It would be easy to leave a directory in the PageFile that Window code would understand as an inventory or instructions. I do not know that my conclusions are correct, but I know what can be done, and I do know what is logical.

Microsoft has never published a paper on exactly what they do with the Page file. Most opinions about what the pagefile is used for, comes from experiments users have performed. These users do not know how the pagefile is used, all they know is that program has problems when the pagefile is disabled. I am just another one of these people. I cannot prove you are wrong or I am right, but there is a lot of things that I have seen that point to me being right.

There will be no loss in functionality except for hibernation which requires an intact pagefile.
Think about what you just said. Ask yourself why. Logically, the PageFile is being used to back-up physical memory during hibernation. Physical memory will not retain data when the computer is off, the PageFile will. If the PageFile is not being used to back-up physical memory , why would the PageFile be needed for the computer to be able to hibernate?

 

[LMiller7]

Luke Warm

I too am a programmer (amateur) and have studied the Windows memory management system extensively. I stand by everything I said previously. You appear to have some misconceptions about how Windows manages memory and how the pagefile is used.

 

[Luke Warm]

Luke Warm

I too am a programmer (amateur) and have studied the Windows memory management system extensively. I stand by everything I said previously. You appear to have some misconceptions about how Windows manages memory and how the pagefile is used.

DiDo
You did not debunk my logic, this is your opportunity to learn something new.

I am a United States Air Force trained aircraft electronics technician. In the world of computers, no one knows everything. I am a Hardware Specialist. I have 9 computers on a network at my house. I have been repairing office equipment for 35 years and I now have a computer repair business. I, like you, am an also amateur programmer.

I did ask a professional programmer today. He said that applications can and do access the pagefile through Windows. And programs can have Pagefile use written into them.
I also ask him if the pagefile is ever used to back-up physical memory. He said it's possible, but he did not know.

 

[Luke Warm]

Luke Warm

I too am a programmer (amateur) and have studied the Windows memory management system extensively. I stand by everything I said previously. You appear to have some misconceptions about how Windows manages memory and how the pagefile is used.

Commit charge - Wikipedia, the free encyclopedia
"The commit charge increases when any program is opened and used, and goes down when a program is closed. It will also change when already-running programs allocate or free private virtual memory; for example, with the VirtualAlloc and VirtualFree APIs."

As a programmer, you will understand the above quote:
If a program has private virtual memory APIs, that would mean that applications do access the PageFile through Windows, and a program can have PageFile use written into it.

As for "the pagefile is used for physical memory back-up", I still have no proof. That conclusion is a product of reverse engineering on my part. I think VirtualAlloc APIs could be used for this. Farther discussion from anyone that has proof one way or the other, is welcome.

 

[LMiller7]

If a program has private virtual memory, that would mean that applications do access the PageFile through Windows, and a program can have PageFile use written into it.

Private use virtual memory is backed by the pagefile. But when or if this memory is ever written to the pagefile is entirely up to the memory management system. Applications do not control this. Any attempt by an application to open the pagefile for any access will fail.

Applications use functions that may access the pagefile. But the application has no control over when or if this occurs. That is my point.

a program can have PageFile use written into it.

Show me an API function that can do this. Otherwise I see no point in continuing this.

 

[Luke Warm]

If a program has private virtual memory, that would mean that applications do access the PageFile through Windows, and a program can have PageFile use written into it.

Private use virtual memory is backed by the pagefile. But when or if this memory is ever written to the pagefile is entirely up to the memory management system. Applications do not control this. Any attempt by an application to open the pagefile for any access will fail.

Applications use functions that may access the pagefile. But the application has no control over when or if this occurs. That is my point.

a program can have PageFile use written into it.

Show me an API function that can do this. Otherwise I see no point in continuing this.

I already did.
The memory management system is controlled by the Operating System, the OS follows instructions from the program.

Quote from; Commit charge - Wikipedia, the free encyclopedia

"The commit charge increases when any program is opened and used, and goes down when a program is closed. It will also change when already-running programs allocate or free private virtual memory; for example, with the VirtualAlloc and VirtualFree APIs."


Quote from; Application programming interface - Wikipedia, the free encyclopedia

"In computer programming, an application programming interface (API) specifies how some software components should interact with each other".


VirtualAlloc API is short for "Virtual memory allocation application programming interface ".

Allocation is another word for "management" or "controlling the way something is used".

al·lo·ca·tion
ˌaləˈkāSHən/
noun
noun: allocation

• 1.
  the action or process of allocating or distributing something.
  "more efficient allocation of resources"
  [TABLE="class: vk_tbl vk_gy"]
  [TR]
  [TD="class: lr_dct_nyms_ttl"]synonyms:
  [/TD]
  [TD]allotment, assignment, distribution, apportionment, sharing out, handing out, dealing out, doling out, giving out, dishing out, parceling out, rationing out, dividing up/out;
  [/TD]
  [/TR]
  [/TABLE]

 

[LMiller7]

I know what VirtualAlloc does. I have used it. It does not read or write to the pagefile.
This is getting nowhere. I will not comment further.

 

[Luke Warm]

I know what VirtualAlloc does. I have used it. It does not read or write to the pagefile.
This is getting nowhere. I will not comment further.

Your right. An API does not read or write to the pagefile, An API is an instruction or a command.

I too know what VirtualAlloc does, but for the people that don't, at the URL below is some good reading for you.
VirtualAlloc function (Windows)

If a program has private virtual memory, that would mean that applications do access the PageFile through Windows, and a program can have PageFile use written into it.

Private use virtual memory is backed by the pagefile. But when or if this memory is ever written to the pagefile is entirely up to the memory management system. Applications do not control this. Any attempt by an application to open the pagefile for any access will fail.

Applications use functions that may access the pagefile. But the application has no control over when or if this occurs. That is my point.

Microsoft disagrees with you. This is a quote from Microsoft directly saying that applications do access Virtual Memory. Access means writing to and reading from "specifically" memory addresses that are located in Virtual Memory.
You can read this Quote at PrefetchVirtualMemory function (Windows)
"The PrefetchVirtualMemory function is targeted at applications that know with reasonable confidence the set of addresses they will be accessing."


Have a good night LMiller7.

 

[Luke Warm]

Some of the things I said in the “how virtual memory works” post, came from reverse engineering on my part. I know how windows works, and I tried to imagine the easiest way that windows might accomplish certain task. Since the post, I have done a lot of research. I have found lots of Microsoft documentation that directly supports my conclusions and none that debunks any of them. I not only stand by what I say, but I back it up with logic and Microsoft documentation.

Here is a list of APIs; these are instructions applications can give to Window to control virtual memory usage.
This is from Memory Management Functions (Windows)

Virtual Memory Functions

The following are the virtual memory functions.

Function	Description
PrefetchVirtualMemory	Prefetches virtual address ranges into physical memory.
VirtualAlloc	Reserves or commits a region of pages in the virtual address space of the calling process.
VirtualAllocEx	Reserves or commits a region of pages in the virtual address space of the specified process.
VirtualAllocExNuma	Reserves or commits a region of memory within the virtual address space of the specified process, and specifies the NUMA node for the physical memory.
VirtualFree	Releases or decommits a region of pages within the virtual address space of the calling process.
VirtualFreeEx	Releases or decommits a region of memory within the virtual address space of a specified process.
VirtualLock	Locks the specified region of the process's virtual address space into physical memory.
VirtualProtect	Changes the access protection on a region of committed pages in the virtual address space of the calling process.
VirtualProtectEx	Changes the access protection on a region of committed pages in the virtual address space of the calling process.
VirtualQuery	Provides information about a range of pages in the virtual address space of the calling process.
VirtualQueryEx	Provides information about a range of pages in the virtual address space of the calling process.
VirtualUnlock	Unlocks a specified range of pages in the virtual address space of a process.