Managing Proper Settings for Heap & Stack Reserve vs. Commit Settings

[JKrob1]

Greetings,

Was wondering, is there any documentation, guidance, FAQ's, etc. toward how to properly set the compiler Heap & Stack settings as well as to properly use the Reserve vs. Commit settings? Been programming w/ Fortran since DVF but only recently been impacted by 'virtual memory' management run-time errors when processing larger datasets. Would like to avoid these situations in the future but not sure how to properly set them - I presume there are trade-offs as to if the settings are too big or too small.

Thanks in advance,

Jeff

[jimdempseyatthecove]

Reserve is the amount of virtual memory address space to be available for stack (of the process main thread).

Commit is virtual memory allocation chunk size of pagefile and RAM allocated each time it is acquired (upon first touch within that chunk of stack).

Additional threads created by the process are not necessarily given these values and you must provide an alternate means. For example, by setting OMP_STACKSIZE or KMP_STACKSIZE environment variables or calling KMP_SET_STACKSIZE/KMP_SET_STACKSIZE_S subroutines prior to creating the OpenMP thread pool.

The heap size is (generally) what's available in the page file (although the O/S or other tool may have a setting on the limit for a process).

Jim Dempsey

[Steve_Lionel]

Stack Reserve is the only setting you should consider changing, and don't make it arbitrarily high as that can prevent the program from running at all. If it is too small, you will get stack overflow or, sometimes, access violation errors. Other errors referring to memory management are not affected by these settings.

[JKrob1]

Ok...with that in mind, have a situation with my data conversion utility. Keep in mind, the data files it has to work through will vary in size so I need to try & anticipate what the largest file pack may be & program toward that. Everything has been running fine for years then a user contacts me with the utility crashing part way through the conversion process. He sends me the log & access to the data file & the crash message is the "Runtime error 41, insufficient virtual memory". Looking at the Stack settings, Reserve is at 0x50000000 (1.3Gb) & Commit is blank. On a whim, I make the Commit 0x50000000 also...and it works! The utility crunches through the entire data set & no crash. Then, I start experimenting - I start reducing the Reserve & Commit and watch what happens. I was able to reduce the Reserve & Commit to 0x30000000 (805 Mb) I still function correctly. I presume that was a savings of 500 Mb of system resources.

This brought my question - how is one supposed to calculate & allocate the amount of memory resources to ensure proper operation while 1) not short-sheeting yourself needed memory 2) not consuming unnecessary system resources which could impact other operations.

Thanks in advance,

Jeff

[jimdempseyatthecove]

>> "Runtime error 41, insufficient virtual memory"

This is not the same as stack overflow. This reports that the page file is completely consumed.

>>Looking at the Stack settings, Reserve is at 0x50000000 (1.3Gb) & Commit is blank. On a whim, I make the Commit 0x50000000 also...and it works! ... reduce...805 MB...

This behavior is indicative of a combination of factors

1) The page file is too small. The (Windows) default size is that of the physical RAM. All the running applications and services and pageable portions of the O/S share this. You can change this Start | System Settings | About | Advanced system settings | Performance | Advanced | Virtual Memory (your click path may differ). Defer doing this until after reading 2) below.

2) The program appears to execute in two principal phases: a) an initial phase that performs a lot of heap allocations, deallocations, allocations, deallocations, allocations deallocations etc..., etc..., etc... causing heap memory fragmentation (and growth/consumption of Virtual Memory), and then b) a computational section that has large stack allocation requirements. By setting the commit size (pre-reserving page file space) this forces the heap allocator to experience a non-failing "insufficient virtual memory" whereby it then consolidates heap fragments to the point of (hopefully) having a successful allocation.

From the reported behavior I would suggest you first try enabling low-fragmentation heap See:

https://docs.microsoft.com/en-us/windows/win32/memory/low-fragmentation-heap

https://docs.microsoft.com/en-us/windows/win32/api/heapapi/nf-heapapi-getprocessheap

https://docs.microsoft.com/en-us/windows/win32/api/heapapi/nf-heapapi-heapsetinformation

Hint, take the example program in the 3rd link and convert it into a void function taking no arguments (IOW leave it as .cpp). A good name might be EnableLowFragmentationHeap. Then place a call to this function (you may need an interface with BIND(C)).

Then experiment with using the original failing setting (Reserve is at 0x50000000 (1.3Gb) & Commit is blank) and re-run your formerly failing test program. If this runs without failure, then this configuration will be most conservative usage of the page file. If this fails, then you will have to resort to setting the commit to an appropriate size and/or enlarging the page file size. Setting an overly large commit size will consume page file size whether used or not. While this may run the program on a lightly used test system, it may fail under normal use when other applications are run on the system at the same time (and requiring some of the page file).

Jim Dempsey

[jimdempseyatthecove]

Add, unnecessary consumption of the page file by your application may result in other applications getting:  "Runtime error 41, insufficient virtual memory".

Jim Dempsey