Avoid integer overflow on ARM machine with 8G of memory

[cshung]

Fixes #65466

On Raspberry Pi 4 model d03114, there is 8G of physical memory.

If we install the ARM dotnet SDK and run an application there, GetGCMemoryInfo.TotalAvailableMemoryBytes would return a negative number, and that is because we are hitting an integer overflow with the multiplication in this change.

Note that sysconf returns a long and that is a signed 32-bit number on ARM.

I confirmed that the negative value no longer repros on that machine, and it reports a number close to 8G.

[ghost]

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes #65466

On Raspberry Pi 4 model d03114, there is 8G of physical memory.

If we install the ARM dotnet SDK and run an application there, GetGCMemoryInfo.TotalAvailableMemoryBytes would return a negative number, and that is because we are hitting an integer overflow with the multiplication in this change.

Note that sysconf returns a long and that is a signed 32-bit number on ARM.

I confirmed that the negative value no longer repros on that machine, and it reports a number close to 8G.

Author:	cshung
Assignees:	cshung
Labels:	area-GC-coreclr
Milestone:	7.0.0

[janvorli]

LGTM, thank you!

[jkotas]

Can you fix the same issue in the standalone GC PAL:

runtime/src/coreclr/gc/unix/gcenv.unix.cpp

Line 1232 in 2201016

return pages * pageSize;

[Maoni0]

wouldn't be better if we just used unsigned exclusively here?

uint64_t physical_memory;
// Get the Physical memory size
physical_memory = ((uint64_t)sysconf( _SC_PHYS_PAGES )) * ((uint64_t) sysconf( _SC_PAGE_SIZE ));

[jkotas]

Test failure tracked by #73299