Memory available to vb.net programs

[Jrhaynes]

I am curious as to the memory available for use when using vb.net with managed memory. Our application uses large arrays. We noticed that when there is an out of memory error and we reduce the size to just barely fit, then the same setup will also run on machines with much less installed memory. In effect no mater how much memory is installed, it seems that exactly the same amount is available across several machines using Windows XP. I tested this with a small program that simply creates arrays that start too large then reduce step by step until it forms without error (collecting at each step), then calculated the MBs in the array. The calculated value on a 2GB machine was 570.8MB. Then using two other machines, a laptop with 1GB and a desktop with 1GB, I run the program and get exactly 570.8MB on those as well. In each case, the task manager gives different and larger values of the memory available. Does anyone have a simple explanation of why more memory isn't available for vb.net no mater how much installed memory is present?

 

[macleod1021]

It's a memory manager app that runs within Windows. If memory serves, 32-bit windows maps out to 4GB of memory. The swap file is then used to imitate the 4GB.

At least that's how I understand it

 

[BobRodes]

But...but...how is he getting 570.8 MB of available memory if we're using the memory manager app that runs in Windows? I did a little digging around to see if I could find an answer to that one, and I didn't find anything definitive. I did find a possible clue, however. The CLR gets loaded via MSCOREE.DLL, which in turn evaluates the system at hand and loads either MSCORWKS.DLL (workstation version of core libraries) or MSCORSVR.DLL (the server version), depending on the type of system involved. From what I can find, the SVR version only loads when multiple processors are present. I found a sniff of an idea that one can force the SVR version to load with code, but that code is unmanaged.

Now, the reason I'm going on about this is because I suspect that the memory allocation requirements are defined here. As such, the idea that the SVR version allocates more memory is worth looking into.

 

[Jrhaynes]

My calculated memory usage is the nominal byte usage of the type for each element in a square array. My test program optionally does the test with single or double types. The same MB value occurs with either type, although the array is larger with single type, so it is clearly a memory limit and not a dimension limit.

Some more tests I have conducted..

1) If the program has accessed any file open or file save dialog, even if later disposed and collected, the memory available is always 570MB. But, If not, then the memory available is exactly 794MB. The difference does not seem to be recoverable (short of exiting and rerunning the program) once it is lost by showing a file system dialog.

2) I have tried resetting page filing and virtual memory etc and see no change across all our computers with different installed memory levels and different settings, however, all are Window XP at this point. The values seem to be hard limits across all our setups.

I was mainly curious as to whether this is a Windows limitation, a .Net limitation, or a VB.net limitation.

 

[Sorwen]

While I can't answer your question I can say that VB.net (2K5) does have several Microsoft undocumented limitations for objects and such. Someone else may have documentation of these limitations, but none of the Microsoft documents have ever list any of the few of them I have found. They could all be actually related back to memory management in some way, but not that I can confirm.


-I hate Microsoft!
-Forever and always forward.

 

[BobRodes]

I don't believe that it would be a vb.net as opposed to a .net limitation, given that you're running these tests compiled. Otherwise, it's possible that it's a limitation of running in debug mode.