Location of `locale.physicalMemory`

[jabraham17]

The MemDiagnostics (which is currently marked unstable) module defines a method on locales to query the physical memory present on a locale.

proc locale.physicalMemory(unit: MemUnits=MemUnits.Bytes, type retType=int(64))

Is this defined in the right place? Would it make more sense to be defined in ChapelLocale.chpl? Or somewhere else?

A few notes on this:

• There are several places in the examples and performance tests where the unstable MemDiagnostics module is included solely to use this method.
• This method doesn't quite match the "theme" of the other functions in the module, which are for tracking memory dynamically whereas this method is for querying a static value.
• A note in the documentation for locale.physicalMemory: "Unlike the other procedures in the MemDiagnostics module, this one does not require memory tracking to be enabled." I think this is a good reason to move it out of the module.
• The MemDiagnostics module defines enum MemUnits, which is defined solely to be used with locale.physicalMemory. I think a decision to move the method out of this module should consider this, particularly naming (ie camelCase) and the values of a GB. Is it 1024**3 or 1000**3, the symbol is unfortunately ambiguous.

[bradcray]

My (reasonably strong) inclination here would be to make locale.physicalMemory() a primary/secondary method on the locale type (that is, one that's defined alongside the type itself). It feels like an innate property of a locale and not something that should require using a standard module to query.

I suspect that the enum is the main reason that we didn't do this from the start (though this is truly ancient code that's been in the memory module from the start, so who knows what we were thinking back then?), and for simplicity, we may just want to deprecate support for the enum (and the optional return type) at the same time that we move the routine, and rely on the user to do the math to convert bytes to another form for now, with the option to beef up the interface over time (specifically, I don't think we'd want this enum to be auto-available to all Chapel programs just because the locale type is... at least in the 2.0 timeframe).

In saying that, I haven't looked at existing use cases to see how heavily those arguments are used in "real codes".