On Thursday, 24 October 2013 at 19:53:56 UTC, Andrei Alexandrescu
wrote:
> Hello,
>
>
> I know it's been a long wait. Hopefully it was worth it. The alpha release of untyped allocators is ready for tire-kicking and a test drive.

About time! ;)  But it was definitely worth waiting for.  I don't
have that much experience with using custom allocators, but
API-wise, this looks great.  Not overburdened, but not underpowered either.

I would suggest a different name for goodAllocSize(), though.
Maybe actualAllocSize() or just allocSize().

This may be a stupid question, but is expand() useful outside the
allocator infrastructure itself?  Would you ever use that instead
of reallocate() in a container, for instance?

Lars

On Sunday, 27 October 2013 at 10:45:31 UTC, Andrei Alexandrescu wrote:
> Just implemented AlignedMallocator and pushed.
>
> http://erdani.com/d/phobos-prerelease/std_allocator.html#.AlignedMallocator
>
> Untested on Windows.

It seems inconsistent that allocate() forwards to alignedAllocate(), while reallocate() does not forward to alignedReallocate().  Why is this?

Lars

On 10/28/13 1:03 AM, Lars T. Kyllingstad wrote:
> On Sunday, 27 October 2013 at 10:45:31 UTC, Andrei Alexandrescu wrote:
>> Just implemented AlignedMallocator and pushed.
>>
>> http://erdani.com/d/phobos-prerelease/std_allocator.html#.AlignedMallocator
>>
>>
>> Untested on Windows.
>
> It seems inconsistent that allocate() forwards to alignedAllocate(),
> while reallocate() does not forward to alignedReallocate().  Why is this?
>
> Lars

Two reasons: (1) Posix does not support aligned reallocation. That would make forwarding a pessimization on that OS; (2) On Windows, realloc() cannot be applied to memory gotten with _aligned_malloc and vice versa.

Andrei

On 10/28/13 8:15 AM, Andrei Alexandrescu wrote:
> On 10/28/13 1:03 AM, Lars T. Kyllingstad wrote:
>> On Sunday, 27 October 2013 at 10:45:31 UTC, Andrei Alexandrescu wrote:
>>> Just implemented AlignedMallocator and pushed.
>>>
>>> http://erdani.com/d/phobos-prerelease/std_allocator.html#.AlignedMallocator
>>>
>>>
>>>
>>> Untested on Windows.
>>
>> It seems inconsistent that allocate() forwards to alignedAllocate(),
>> while reallocate() does not forward to alignedReallocate().  Why is this?
>>
>> Lars
>
> Two reasons: (1) Posix does not support aligned reallocation. That would
> make forwarding a pessimization on that OS; (2) On Windows, realloc()
> cannot be applied to memory gotten with _aligned_malloc and vice versa.
>
> Andrei

Oh, my mistake. On Windows reallocate() should forward to alignedReallocate.

Andrei

On Thursday, 24 October 2013 at 19:53:56 UTC, Andrei Alexandrescu wrote:
>
> Please destroy! I've literally sweat as I'm sending this :o).
>
>
> Andrei

Going through the code today after reading the thread for the past few days I was blown away by the depth of the concepts involved. Now the information in the article "Memory Allocation: Either Love It or Hate It (or just think it’s okay)" makes a lot more sense. The composability and customizability of the design look good. This is not an area of coding that I am that familiar with but I am interested in trying out a couple of ideas using the code in the coming weeks.

I had a good laugh when I saw the ASCII art before the definition of NullAllocator. Pretty cool!

Thanks for this work.

Joseph

On 10/25/2013 03:08 AM, Walter Bright wrote:
> Would it be possible that this use the "package" idea with one allocator
> per file instead of the all-in-one-file setup?

I'd like to see that as well.

On 10/24/2013 09:54 PM, Andrei Alexandrescu wrote:
> Hello,
>
>
> I know it's been a long wait. Hopefully it was worth it. The alpha
> release of untyped allocators is ready for tire-kicking and a test drive.
>
> Code: https://github.com/andralex/phobos/blob/allocator/std/allocator.d
>
> Dox: http://erdani.com/d/phobos-prerelease/std_allocator.html

This looks really promising.
There are a lot of building blocks and the way different capabilities are modelled by optional methods nicely solves the biggest difficulty with allocators.
I think it's important to put this in it's own github repo and add a dub package for it on code.dlang.org so that it's easy to test the implementation and to contribute improvements.

That said it failed my litmus test.
I previously used David Simcha's RegionAllocator
https://github.com/dsimcha/TempAlloc/blob/master/std/allocators/region.d.

The pattern is to allocate some metadata followed by allocating many fixed size tree nodes. When the tree is constructed it is used to render an image which is the result of that operation.
The tree and all metadata is freed and the region allocator is reused for the next method invocation (it keeps the memory).

I think the closest would be to use CascadingAllocator with Region but there are two issues.

CascadingAllocator successively tries all allocators and if that fails creates a new region. So this runs in O(N) complexity even though most of the time only the last allocator will have memory available.

There is no simple way to deallocateAll without freeing the regions.
What I need is something similar to clear in appender.
I also can't relinquish the memory from the inner regions because they are private.

So for my use-case the only way that I found to use this module
is to compute the upper bound of memory needed when the renderer is invoked. Then I have to relinquish the buffer from a region, reallocate it using Mallocator.it and construct a new region with the reallocated buffer.

This works only because I can cheaply compute the upper bound of required memory. This wouldn't work in other scenarios.
I think this a very important use-case, e.g. using an auto-growing thread local region is what I would use to serve HTTP requests.
But for this one might also want to use nested regions.

On 10/27/13, 7:10, Andrei Alexandrescu wrote:
>> The second problem is that the logged file/line is always in
>> std.allocator.d. It's probably not easy to get this working in all
>> cases (especially regarding polymorphism).
>
> Uhm, that /is/ a problem.

This is supported by using default values:

1:import std.stdio;
2:void w(int l = __LINE__){writeln(l);}
3:void main(){w();}

outputs:
3

By design :)

On 10/31/13 8:57 AM, Lionello Lunesu wrote:
> On 10/27/13, 7:10, Andrei Alexandrescu wrote:
>>> The second problem is that the logged file/line is always in
>>> std.allocator.d. It's probably not easy to get this working in all
>>> cases (especially regarding polymorphism).
>>
>> Uhm, that /is/ a problem.
>
> This is supported by using default values:
>
> 1:import std.stdio;
> 2:void w(int l = __LINE__){writeln(l);}
> 3:void main(){w();}
>
> outputs:
> 3
>
> By design :)

The problem is only in CAllocator.

Andrei

I noticed that the GCAllocator provides no way of controlling the memory block attributes (http://dlang.org/phobos/core_memory.html#.GC.BlkAttr ,) all allocations get the default (no attributes.) This is a leaky abstraction, a data structure or composed allocators may desire to control the attributes to reduce GC pressure.