FYI - mo' work on std.allocator
Marco Leise via Digitalmars-d
digitalmars-d at puremagic.com
Sun May 4 20:06:24 PDT 2014
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
More information about the Digitalmars-d
mailing list