FYI - mo' work on std.allocator

[Marco Leise via Digitalmars-d]

Am Sun, 27 Apr 2014 09:01:58 -0700
schrieb Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:

> On 4/27/14, 7:51 AM, bearophile wrote:
> > Andrei Alexandrescu:
> >
> >> Destruction is as always welcome. I plan to get into tracing tomorrow
> >> morning.
> >
> > How easy is to implement a OS-portable (disk-backed) virtual memory
> > scheme using std.allocator? :-) Is it a good idea to include one such
> > scheme in std.allocator?
> >
> > Bye,
> > bearophile
> 
> I just added MmapAllocator:
> 
> http://erdani.com/d/phobos-prerelease/std_allocator.html#.MmapAllocator
> 
> If anyone would like to add a Windows implementation, that would be great.
> 
> 
> Andrei

Virtual memory allocators seem obvious, but there are some
details to consider.

1) You should not hard code the allocation granularity in the
   long term. It is fairly easy to get it on Windows and Posix
   systems:

On Windows:
  SYSTEM_INFO si;
  GetSystemInfo(&si);
  return si.allocationGranularity;

On Posix:
  return sysconf(_SC_PAGESIZE);

2) For embedded Linux systems there is the flag
   MAP_UNINITIALIZED to break the guarantee of getting
   zeroed-out memory. So if it is desired, »zeroesAllocations«
   could be a writable property there.

In the cases where I used virtual memory, I often wanted to
exercise more of its features. As it stands now »MmapAllocator«
works as a basic allocator for 4k blocks of memory. Is that
the intended scope or are you open to supporting all of it?
From the top of my head there is:

- committing/decommitting ranges of memory
- setting protection attributes
- remapping virtual memory pages to other physical pages

Each allows some use cases, that I could expand on if you
want. So it would be beneficial in any case to have those
primitives in a portable form in Phobos. The question is,
should that place be »MmapAllocator« or some std.vm module?

-- 
Marco