On Thursday, 24 October 2013 at 19:53:56 UTC, Andrei Alexandrescu wrote:
>
> Code: https://github.com/andralex/phobos/blob/allocator/std/allocator.d
>
> Dox: http://erdani.com/d/phobos-prerelease/std_allocator.html
>

Am I the only one seeing dead links?

Am 11.09.2015 um 04:35 schrieb bitwise:
> On Thursday, 24 October 2013 at 19:53:56 UTC, Andrei Alexandrescu wrote:
>>
>> Code: https://github.com/andralex/phobos/blob/allocator/std/allocator.d
>>
>> Dox: http://erdani.com/d/phobos-prerelease/std_allocator.html
>>
>
> Am I the only one seeing dead links?

The code has moved to std.experimental:
https://github.com/andralex/phobos/tree/allocator/std/experimental/allocator
http://erdani.com/d/phobos-prerelease/std_experimental_allocator.html

On Friday, 25 October 2013 at 00:00:36 UTC, Andrei Alexandrescu wrote:
> 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

Doesn't this race because the allocator instance is shared?

I couldn't find 'setAllocator' in the source code.

   Bit

On 09/11/2015 06:32 PM, bitwise wrote:
> On Friday, 25 October 2013 at 00:00:36 UTC, Andrei Alexandrescu wrote:
>> 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
>
> Doesn't this race because the allocator instance is shared?
>
> I couldn't find 'setAllocator' in the source code.

Yah, that was a rumination, not something already implemented. -- Andrei

On Friday, 11 September 2015 at 23:13:16 UTC, Andrei Alexandrescu wrote:
> On 09/11/2015 06:32 PM, bitwise wrote:
>> On Friday, 25 October 2013 at 00:00:36 UTC, Andrei Alexandrescu wrote:
>>> 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
>>
>> Doesn't this race because the allocator instance is shared?
>>
>> I couldn't find 'setAllocator' in the source code.
>
> Yah, that was a rumination, not something already implemented. -- Andrei

Ok, thanks. I thought that may be the case.

One more question:

I'd like to integrate these into the containers I'm building, but I'm not clear about how to determine if GC.addRange() should be called.

I've thought through this, and I'm pretty sure that I can call GC.addRange and GC.removeRange indiscriminately on any memory my container gets from an allocator, as long as the container finds that (hasIndirections!T == true).

My reasoning is that if an allocator calls GC.addRange on it's own memory, then it should also reinitialize that memory when it gets deallocated, which would include calling GC.addRange again if it had to. Also, calling GC.addRange or GC.removeRange on GC allocated memory should have no effect.

Does this sound right, or am I crazy?

   Bit

On 09/11/2015 07:46 PM, bitwise wrote:
> On Friday, 11 September 2015 at 23:13:16 UTC, Andrei Alexandrescu wrote:
>> On 09/11/2015 06:32 PM, bitwise wrote:
>>> On Friday, 25 October 2013 at 00:00:36 UTC, Andrei Alexandrescu wrote:
>>>> 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
>>>
>>> Doesn't this race because the allocator instance is shared?
>>>
>>> I couldn't find 'setAllocator' in the source code.
>>
>> Yah, that was a rumination, not something already implemented. -- Andrei
>
> Ok, thanks. I thought that may be the case.
>
> One more question:
>
> I'd like to integrate these into the containers I'm building, but I'm
> not clear about how to determine if GC.addRange() should be called.
>
> I've thought through this, and I'm pretty sure that I can call
> GC.addRange and GC.removeRange indiscriminately on any memory my
> container gets from an allocator, as long as the container finds that
> (hasIndirections!T == true).
>
> My reasoning is that if an allocator calls GC.addRange on it's own
> memory, then it should also reinitialize that memory when it gets
> deallocated, which would include calling GC.addRange again if it had to.
> Also, calling GC.addRange or GC.removeRange on GC allocated memory
> should have no effect.
>
> Does this sound right, or am I crazy?

Say you have a container that uses its own allocator inside, yet offers the user to store objects with indirections that use the GC. Then indeed the container would need to call addRange and removeRange on its own internal structures.

If, on the contrary, the container imposes that its own held objects use the container's allocator as well (a rare but not implausible design), it wouldn't need to do that.


Andrei

On Saturday, 12 September 2015 at 00:31:27 UTC, Andrei Alexandrescu wrote:
> On 09/11/2015 07:46 PM, bitwise wrote:
>> [...]
>
> Say you have a container that uses its own allocator inside, yet offers the user to store objects with indirections that use the GC. Then indeed the container would need to call addRange and removeRange on its own internal structures.

This sounds like the default setup I'll be using. The containers will use a Mallocator by default, so I will have to add the ranges when the contained type is found to have indirections.

> If, on the contrary, the container imposes that its own held objects use the container's allocator as well (a rare but not implausible design), it wouldn't need to do that.

I don't understand exactly what you mean, but here is a more verbose version of my concern:

Lets say someone's allocator calls GC.addRange on the memory it allocates before a container gets it. The container would call GC.addRange when it gets it, but then call GC.removeRange before calling allocator.deallocate(). The allocator which think's the block has already been registered with the GC could possibly reuse it, thinking it's registered with the GC already....but that allocator may pass the memory to a container which chooses not to call GC.addRange, because it thinks it's using an allocator that does that for it. That second container may now store types with indirections, which would be unreachable, and get freed, and......chaos.

I suppose that as a general rule, a container could always add ranges it gets from an allocator to the GC, which would prevent the above problem...but only for containers that abide by the rule. It sounds like you're saying that although it may not be needed sometimes, that no harm would be done.

I think a better solution though would be for the GC to have something like GC.hasRange(). The container could check the state of the memory it receives and take appropriate action. I don't see anything in the current GC docs which would allow you to tell if a range had already been added to the GC.

    Bit

On Saturday, 12 September 2015 at 06:30:42 UTC, bitwise wrote:
> On Saturday, 12 September 2015 at 00:31:27 UTC, Andrei Alexandrescu wrote:
>> [...]
>
> This sounds like the default setup I'll be using. The containers will use a Mallocator by default, so I will have to add the ranges when the contained type is found to have indirections.
>
> [...]

Alternatively, GC.addRange() could return a value indicating whether or not the range had actually been added(for the first time) and should be removed.

   Bit

On Saturday, 12 September 2015 at 06:45:16 UTC, bitwise wrote:
> [...]
>
> Alternatively, GC.addRange() could return a value indicating whether or not the range had actually been added(for the first time) and should be removed.
>
>    Bit

Maybe the solution is as simple as specifying the state of memory that should be received from an untyped allocator.

It could be explicitly stated that an untyped allocator should give out raw memory, and should not initialize it's content or add any ranges to the GC. While it may seem obvious for a C++ allocator not to initialize it's contents, I think this makes sense in the presence of a GC.

I would appreciate some feedback on this.

   Bit

On 09/14/2015 10:46 AM, bitwise wrote:
> On Saturday, 12 September 2015 at 06:45:16 UTC, bitwise wrote:
>> [...]
>>
>> Alternatively, GC.addRange() could return a value indicating whether
>> or not the range had actually been added(for the first time) and
>> should be removed.
>>
>>    Bit
>
> Maybe the solution is as simple as specifying the state of memory that
> should be received from an untyped allocator.
>
> It could be explicitly stated that an untyped allocator should give out
> raw memory, and should not initialize it's content or add any ranges to
> the GC. While it may seem obvious for a C++ allocator not to initialize
> it's contents, I think this makes sense in the presence of a GC.
>
> I would appreciate some feedback on this.
>
>     Bit

I think what we need here is a GCConnectedAllocator that can be inserted at the bottom of the allocation foodchain to insert calls to addRange and removeRange appropriately. -- Andrei