CODEWITHSUNDEEP
windowscommand-lineram
Jonathan Livni
Jonathan Livni

Reputation: 107092

Run program from RAM on Windows

Is there a way to run a program from the command-line in Windows while forcing Windows to retain the process in RAM only without swaping it to disk?

Upvotes: 0

Views: 2132

Answers (1)

Damon
Damon

Reputation: 70126

There is generally no way you can safely and reliably prevent a normal application from seeing page faults (either with load from disk, or just pages rearranged in the pool). It is not normally a problem either.

Page faults (without disk access) happen all the time, and they take a few dozen nanoseconds. Windows routinely moves pages in and out of a very small working set. This does not mean that the pages outside your working set are "gone", but they are possible candidates for being swapped/discarded, if someone asks for more memory. Most of the time, when a page outside your working set is accessed again, it is still there and is just silenly moved back into the working set, pushing another one (presumably the least important one) out.
Reloading pages (data or program code) from disk, which is much slower, does not usually happen very often, as long as the program is actually running and as long as the machine is not desperately low on RAM. And if it happens, frankly, there's not much one could have done differently, because that means there simply was less RAM than was neeeded.

You can use VirtualLock to lock pages of your address space (any pages, including those occupied by code), but this is still no hard guarantee (even though the documentation would make you believe that) and it only works as far as the working set goes, which by default is very little (a little more than 1 MiB).
The best guarantee that locking will give you, however, is that the pages you lock are in RAM while your process is running. Which means, in theory, they might still be swapped out at the next context switch anyway when your process is not running.

However, if you give your application a sufficiently large maximum working set size (SetProcessWorkingSetSize) then page faults (in code, or in general) are extremely unlikely to happen.
Note that the vast majority of programs is resident in memory most of the time even after they have finished running (buffer cache).

Upvotes: 1

Related Questions