FYI - mo' work on std.allocator

[Andrei Alexandrescu via Digitalmars-d]

On 5/4/14, 8:06 PM, Marco Leise wrote:
> 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);

I've decided that runtime-chosen page sizes are too much of a 
complication for the benefits.

> 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.

This can be easily done, but from what MAP_UNINITIALIZED is strongly 
discouraged and only implemented on small embedded systems.

> 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?

For now I just wanted to get a basic mmap-based allocator off the 
ground. I am aware there's a bunch of things to do. The most prominent 
is that (according to Jason Evans) Linux is pretty bad at munmap() so 
it's actually better to advise() pages away upon deallocation but never 
unmap them.


Andrei