The Xpost_Memory_File data structure and supporting code are a big rats-nest of #ifdefs and workarounds that permit some useful flexibility:
uses mmap and mremap if available for fast management of big pages of data
uses mmap, simulating mremap for half-fast management
uses malloc and realloc for widest portability
In the malloc compilation path, it attempts to emulate mmap's ability to make an ANONYMOUS mapping or to associate the memory with a file on disk that is synchronized with the memory. This *almost* supports this extra intended features:
extra memory file dumper/validator utility for analyzing failures and bug-reports
memory-image caching to factor-out the loading and reading of
init.ps and friends (quick-launch)
So it would simplify the code to remove the file-backing iff we're willing to give up on these other features. OTOH there are at least 3 big steps in the way of achieving them.
Memory Tables for the Memory File are now outside of the memory in a separate malloc'd area. So the memory is not self-contained anymore.
The itpdata structure which holds the associations between memories and contexts is also outside of the memory.
And of course the dumper/validator program is not written. It would depend on the details of these other issues.
Another problem is we now have 2 distinct things both called "memory file". One that is primarily memory but with a file behind; and the other I'm now writing which is primarily a file but with a string behind.
The solution I've chosen here, not completely satisfactory, is to name the new string-backed file Xpost_MemFile, like Xpost_DiskFile which is the other subclass or implementation of the abstract Xpost_File virtual class or interface.