"Fix" multilocale memory tracking
"Fix" multilocale memory tracking

[reviewed by Greg and David]

This commit "fixes" (more on the quotes below) multilocale memory
tracking, which has actually been broken since r22257.  The issue is
that we were trying to access strings (logfile names) from a remote
locale from within the runtime during memory tracking initialization
in chpl_memTracking_returnConfigVals().  This bug was mostly masked
because we don't test multilocale memory tracking with explicit
logfiles, but it broke the gasnet configuration on OSX with the big
c_string commit (r23558).

This commit actually abuses a current unexpected behavior in the
compiler where under certain circumstances, strings are copied to
remote locales.  In this specific case, when the locale.id is
accessed, the string is copied from locale 0 to the remote locale, and
can be assigned to a local temporary string which can then be passed
to the runtime.  When the string implementation is revamped using
records, we will simply change the locale.id access to one that checks
here.id.

FYI, Greg will be committing a test that locks in the correct behavior
for multilocale memory tracking.



git-svn-id: 88467cb1fb04b8a755be7e1ee1026be4190196ef@23777 3a8e244f-b0f2-452b-bcba-4c88e055c3ca

chizarlicious/chapel,CoryMcCartan/chapel,hildeth/chapel,CoryMcCartan/chapel,CoryMcCartan/chapel,hildeth/chapel,chizarlicious/chapel,chizarlicious/chapel,chizarlicious/chapel,CoryMcCartan/chapel,chizarlicious/chapel,chizarlicious/chapel,sungeunchoi/chapel,hildeth/chapel,chizarlicious/chapel,sungeunchoi/chapel,sungeunchoi/chapel,sungeunchoi/chapel,CoryMcCartan/chapel,CoryMcCartan/chapel,hildeth/chapel,hildeth/chapel,CoryMcCartan/chapel,sungeunchoi/chapel,sungeunchoi/chapel,sungeunchoi/chapel,hildeth/chapel,hildeth/chapel,sungeunchoi/chapel