On 10/24/13 2:31 PM, Namespace wrote:
> Awesome! Will Appender get an option to use a suitable allocator?

Well there's the matter of defining typed allocators on top of these ones. But yes, once we have allocators in place, they will become part of the Phobos' APIs they can serve.

Andrei

On Thursday, 24 October 2013 at 19:53:56 UTC, Andrei Alexandrescu wrote:
> 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.

Very, very nice!

One question that immediately jumps out for me:

As a primitive, will deallocateAll always call the parent's deallocate/deallocateAll?

Sometimes it's useful to tell a top-level allocator to forget it allocated anything, but not actually free memory, so that it can be reused - similarly to Appender's clear method. There doesn't seem to be an easy way to do it with Freelist, as it will always forward to the parent's deallocate or deallocateAll. Perhaps there could be a "clear" primitive too?

Spied two typos:
- s/AllocatorWithOptions/AllocatorWithStats/
- s/an the call/the call/

Am Thu, 24 Oct 2013 12:54:41 -0700
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> Please destroy! I've literally sweat as I'm sending this :o).
> 
> Andrei

1) »FallbackAllocator is an the allocator equivalent of an "or" operator in algebra.«

Remove the "the" there.


2) FallbackAllocator!(InSituRegion!16384, GCAllocator) a;

Awesome, I actually use stuff like this.


3) // Same as above, except the freelist only applies to the reap.

What is a reap? Is my English just bad or did 'h' get replaced with 'r' here a few times?


4) »For example, (D HeapBlock!(Allocator, 4096) (described in
detail below) …«

Broken DDoc macro.


The class wrapper at the end is a nice addition to the set of allocators. It seems like a good pattern to have in D with the constant mix of class hierarchies and value types.

-- 
Marco

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.
>
> Code: https://github.com/andralex/phobos/blob/allocator/std/allocator.d
>
> Dox: http://erdani.com/d/phobos-prerelease/std_allocator.html
>
> Warning: this is alpha quality. Unit tests are thin, and there are no benchmarks. Both would be appreciated, particularly benchmarks to validate the gains (which I speculate can be very sizable) of custom-built, special-purpose allocators compared to traditional allocators.
>
> I acknowledge I'm clearly in no position to evaluate this design. I have been knocking around it for long enough to have no idea how easy it is to get into it from the outside, or how good it is. By all signs I could gather this feels like good design, and one of the best I've ever put together. The allocators defined have an archetypal feeling, are flexible both statically and dynamically, and morph and combine in infinite ways.
>
> CAllocator and CAllocatorImpl make the link between the static and dynamic worlds. Once an allocator is assembled out of pieces and finely tuned, wrapping it in a dynamic API is a snap.
>
> Please destroy! I've literally sweat as I'm sending this :o).
>
>
> Andrei

I'm nowhere near experienced enough to comment on how good this really is, but it sure looks like an impressive design. Congratulations :)

On 10/24/13, Namespace <rswhite4@googlemail.com> wrote:
> A dream of me, that will probably never come true, would be also something like this:
> ----
> with (Mallocator) {
>      int[] arr;
>      arr ~= 42; /// will use Mallocator.it.allocate internal
> }
> ----
>

Actually this got me thinking..

import core.memory;

GC.useAllocator!Mallocator;
int[] arr;
arr ~= 42;

This could be a useful test-bed for the allocators by using them with existing D applications and libraries that depend on the GC (most apps I'd assume).

On Thursday, 24 October 2013 at 21:44:43 UTC, Vladimir Panteleev wrote:
> On Thursday, 24 October 2013 at 19:53:56 UTC, Andrei Alexandrescu wrote:
>> 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.

A nitpick:

FallbackAllocator!(InSituRegion!..., ...) can be faster by defining a specialized allocator as a Region, which is initialized with the slice of a static buffer, and once that is filled up, a new buffer. This avoids a conditional branch in FallbackAllocator (we'd be reusing the same branch that checks for a full buffer and returns null in Region). This combination will likely be used often so it might be worth optimizing this use case, but OTOH the FallbackAllocator conditional branch will likely be subject to good branch prediction, so at least on x86 the gain might be minimal.

On Thursday, 24 October 2013 at 21:57:10 UTC, Marco Leise wrote:
> 3) // Same as above, except the freelist only applies to the
> reap.
>
> What is a reap? Is my English just bad or did 'h' get replaced
> with 'r' here a few times?

A reap mixes region and heap.

Previous discussion:
http://forum.dlang.org/post/aikhlqoffaznpkugesev@forum.dlang.org

Paper:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.7.6505&rep=rep1&type=pdf

On Thursday, 24 October 2013 at 21:57:10 UTC, Marco Leise wrote:
> 3) // Same as above, except the freelist only applies to the
> reap.
>
> What is a reap? Is my English just bad or did 'h' get replaced
> with 'r' here a few times?

Reap = region + heap. I believe the term originates from this 2002 paper:
http://people.cs.umass.edu/~emery/pubs/berger-oopsla2002.pdf

Andrei mentioned them in this 2008 talk:
http://accu.org/content/conf2008/Alexandrescu-memory-allocation.screen.pdf

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.
>
> Code: https://github.com/andralex/phobos/blob/allocator/std/allocator.d
>
> Dox: http://erdani.com/d/phobos-prerelease/std_allocator.html

I admit, I don't use custom allocators as much as I should and am not as experienced in this topic as others, yet for my purposes this design seems excellent. The docs are solid, and I really like the idea of just being able to composite something like AllocatorWithStats. The use cases I had in mind (which are admittedly quite simple) are covered, and it's very clear how to add a custom allocator if desired.

A couple of questions:
Shouldn't most of these implementations be marked nothrow? I could be missing something here.
For CAllocator, I notice setting alignment is a property yet does not return void. Does this not go against the idea of @property? Perhaps it should be setAlignment instead?

On Thursday, 24 October 2013 at 21:58:36 UTC, Andrej Mitrovic wrote:
> On 10/24/13, Namespace <rswhite4@googlemail.com> wrote:
>> A dream of me, that will probably never come true, would be also
>> something like this:
>> ----
>> with (Mallocator) {
>>      int[] arr;
>>      arr ~= 42; /// will use Mallocator.it.allocate internal
>> }
>> ----
>>
>
> Actually this got me thinking..
>
> import core.memory;
>
> GC.useAllocator!Mallocator;
> int[] arr;
> arr ~= 42;
>
> This could be a useful test-bed for the allocators by using them with
> existing D applications and libraries that depend on the GC (most apps
> I'd assume).

That would be really awesome. I would test it immediately and extensively. :)