FYI - mo' work on std.allocator

[Marco Leise via Digitalmars-d]

Am Sun, 04 May 2014 21:05:01 -0700
schrieb Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:

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

Alright. Note however, that on Windows the allocation
granularity is larger than the page size (64 KiB). So it is a
cleaner design in my eyes to use portable wrappers around page
size and allocation granularity.

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

Agreed.

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

That sounds like a more complicated topic than anything I had
in mind. I think a »std.virtualmemory« module should already
implement all the primitives in a portable form, so we don't
have to do that again for the next use case. Since
cross-platform code is always hard to get right, it could also
avoid latent bugs.
That module would also offer functionality to get the page
size and allocation granularity and wrappers for common needs
like getting n KiB of writable memory. Management however
(i.e. RAII structs) would not be part of it.
It sounds like not too much work with great benefit for a
systems programming language.

-- 
Marco