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
