Wrong display of memory consumption in HUD when LAA

[BB25187]

When LAA is used, and memory consumption exceeds 2Gb, the HUD information is wrong:
- The value dumped becomes negative
- No curve is diplayed in the graph view

The problem is linked to the way this value is retrieved in HUDWindow.cs, which is based on a 32bits signed integer. With this type, one cannot represent a value larger than 2Gb without overflow / wrap around behavior. Changing it into an unsigned integer resolves the issue - one can then represent a memory consumption as large as 4Gb. A wider type could be used to represent even larger values.

Besides this first fix, the range of the graph should be set to 4Gb instead of 2Gb, to be consistent with the LAA option.

[James Ross (twpol)]

So, I don't want the display to show 4GB when we're not using LAA, and if we want to be pedantic (I'm not sure we do) if you use the LAA version on a 32bit system with 3GB tuning enabled, it should be 3GB. :)

[BB25187 (bb25187)]

The new version of the patch checks at runtime:
- If the process is a 32b or 64b one (not really needed for the moment, but verified conservatively)
- If the OS is 32b or 64b
- If the LAA option is ticked and LAA file exists
It adjusts the range of the memory graph accordingly (2Gb, 3Gb or 4Gb).
I could test it on 64b system only.

Though, the most important and generic part of the fix is the change of type to avoid negative values in HUD when memory consumption is higher that 2Gb.

[Carlo Santucci (carlosanit1)]

When I'll have a short moment of time I will test it on my 32b system. Only an issue: to get 3 GB available on a 32b system two conditions must be accomplished: the LAA version must be run and that the so-called "3GB switch" must be enabled ( http://knowledge.autodesk.com/support/autocad/troubleshooting/caas/sfdcarticles/sfdcarticles/How-to-enable-a-3GB-switch-on-Windows-Vista-Windows-7-or-Windows-XP-s.html ). Do you check both conditions with a 32b system?

[BB25187 (bb25187)]

The patch doesn't verify if the 3Gb switch is turned on. Thus, the scale of the graph is always 0-3Gb when one uses the LAA binary on a 32b OS. I didn't check if the switch could be easily tested at runtime, but I am not sure this is worth the price (it also depends on the desired semantics of this scale)?
Note that the patch doesn't test the amount of physical memory either. Thus, the scale of the graph is too large if this latter is limited to 2Gb, and memory available to user processes is even smaller. This may happen on PC configured for 32b OS like XP or starter edition of W7).
Another strategy would consist in using system utility functions (e.g. MemoryFailPoint) but then the test would be sensitive to runtime variations of allocatable memory, which is not desirable.

[James Ross (twpol)]

The data and graph have nothing to do with physical memory anyway. I wouldn't worry about testing for the 3GB-tuning switch.

[Carlo Santucci (carlosanit1)]

I have positively tested the patch with my 32bit system, with standard (I got a 2 GB range) and LAA (I got a 3 GB range) Runactivity. So for me the patch can be committed.
I have also found on the Internet how to test the 3GB-tuning switch, but I don't dare to add it to the patch.

[James Ross (twpol)]

Fixed in X2272 in a different way: I'd forgotten we can just query the OS for the maximum virtual memory (for your process) and the maximum physical memory. I've made the graph use the minimum of these two values. (I'd also forgotten that the graph was working set, not used virtual, thus it cannot exceed physical.)

[BB25187 (bb25187)]

Thanks Carlo for the verification and thanks James for this more elegant fix.