FYI - mo' work on std.allocator
safety0ff via Digitalmars-d
digitalmars-d at puremagic.com
Mon May 5 00:13:02 PDT 2014
On Monday, 28 April 2014 at 16:03:33 UTC, Andrei Alexandrescu
wrote:
>
> Fair enough, I'll remove that part of the spec. Thanks! --
> Andrei
According to the docs, the "multiple of sizeof(void*)"
restriction only applies to posix_memalign (and not to
_aligned_malloc and aligned_alloc.)
On Monday, 5 May 2014 at 04:04:56 UTC, Andrei Alexandrescu wrote:
> 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.
Do the complications arise in the MmapAllocator or the higher
level allocators?
I'd like to see a Windows allocator based on VirtualAlloc, and
afterwards a "SystemAllocator" defined to be MmapAllocator on
unix-based and VirtualAlloc based on Windows.
This "SystemAllocator" would ideally have an
allocationGranularity property.
More information about the Digitalmars-d
mailing list