Am Sun, 27 Apr 2014 09:01:58 -0700 schrieb Andrei Alexandrescu <[email protected]>:
> 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
