On Thursday, 24 October 2013 at 22:19:10 UTC, Kapps wrote:
> 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?

Actually, this doesn't make sense because then it would not be possible to use CAllocator instead of an Allocator in a template as the type would be wrong. It still feels a bit odd that it returns bool to me, but I definitely see the logic now.

There was a comment in an earlier reply that's very relevant to mine.  A good demonstration of the utility of these classes is how much of the current (and proposed) garbage collector can be replaced by using this module.  For that to happen, the code needs to actually live in the runtime (at least as things are currently layered).

On 10/24/13 12: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
>
> 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

On Thursday, 24 October 2013 at 22:22:53 UTC, Namespace wrote:
> 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. :)

Another idea would be that every built-in array has a Allocator property which can be set:
----
int[] arr;
arr.allocator = Mallocator;
----

Andrei Alexandrescu:

>> - Can you create an hierarchical allocator with those?
>
> Not sure what that means (I recall the phrase has been discussed but forgot what it means).

I meant something like this:

http://swapped.cc/?_escaped_fragment_=/halloc#!/halloc


> (Including awareness of virtual memory management from the OS).
>
> Definitely!
>
> * http://stackoverflow.com/questions/3839922/aligned-malloc-in-gcc comes to mind.
>
> * http://en.wikipedia.org/wiki/Sbrk
>
> * http://en.wikipedia.org/wiki/Mmap

By that "awareness" I meant something like what the Azul JavaVM does, here a panoramic view of similar ideas:

http://web.eece.maine.edu/~jyue/papers/iccci.pdf

Bye,
bearophile

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

First, I love it !

Now destroying :D

The first thing I notice is that this module is dead unsafe. I'm not sure it belong to std. We should probably reserve that for a "guru" part of the standard lib. Putting some system function in the standard lib is OK, as they are packaged around concepts (range, array, algorithms, etc . . .) but an entire module dedicated to @system stuff seems like it belong to another place.

I see that you did update the whole stuff according to previous discussion, and I'm not sure I have something against the design anymore :D

Now, typed allocators, generic tail const and we can get awesome collections!

On 10/24/13 2:44 PM, 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.
>
> Very, very nice!
>
> One question that immediately jumps out for me:
>
> As a primitive, will deallocateAll always call the parent's
> deallocate/deallocateAll?

That's a gray area for the time being. What I fear (for e.g. HeapBlock) is a pathological case in which deallocateAll frees parent's buffer and then a reallocation grabs another one etc.

Also I haven't forgotten your suggestion returnsZeroedMemory. I think we should implement it at a point.

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

I think that's a good idea.

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

Fixed, thanks.


Andrei

On 10/24/13 2:56 PM, Marco Leise wrote:
> 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.

Fixed, thanks. I see "reap" has been discussed.

Andrei

On 10/24/13 2:38 PM, Namespace wrote:
> On Thursday, 24 October 2013 at 21:31:42 UTC, Namespace wrote:
>> Awesome! Will Appender get an option to use a suitable allocator?
>
> 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
> }
> ----

Oddly enough this can be actually done.

with (setAllocator!Mallocator)
{
   ...
}

setAllcator returns an rvalue that changes the global allocator to the Mallocator in the constructor, and restores it to whatever it was in the destructor.


Andrei

On 10/24/13 3:08 PM, Vladimir Panteleev wrote:
> 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.

Yah, good idea. At some point I have no doubt that intensively-used allocators will be tuned a fair amount.

Andrei

On 10/24/13 3:19 PM, Kapps wrote:
> A couple of questions:
> Shouldn't most of these implementations be marked nothrow? I could be
> missing something here.

Oh yah, that's part of the whole "alpha" thing. Then, since most allocators are templated, I'm hoping language definition will catch up with me and just infer them most of the time.

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

Yah, I'll fix that. Thanks!


Andrei