On 02/13/2016 03:35 AM, Andrei Alexandrescu wrote:
> Folks who defined refcounted types use the special AffixAllocator internally in an encapsulated manner. They define it, they use it - outside intervention is not possible. Those who use their own allocation calls and then use assumeUnique cannot use it on the new types. Or maybe I'm not understanding something.

Ah probably this is the important point I have totally missed. So you envision this kind of metadata support to be only available via specific type of allocator, AffixAllocator, and not being supported by most of them?

On 13.02.2016 01:30, Andrei Alexandrescu wrote:
> On 02/12/2016 06:29 PM, Timon Gehr wrote:
>> The first thing that comes to mind is that accessing a global
>> associative array is not 'pure'.
>
> The weird thing is in this case is. The analogy is limited. -- Andrei

Why is it limited? Accessing the affix isn't pure either. I.e. reference counting will not work in pure code.

On 12.02.2016 20:12, Andrei Alexandrescu wrote:
>
> * If the buffer is mutable, then the allocator assumes it hasn't been
> shared across threads, so it returns a reference to a mutable affix.
>
> * If the buffer is const, then the allocator must conservatively assume
> it might have been immutable and subsequently shared among threads.
> Therefore, several threads may request the affix of the same buffer
> simultaneously. So it returns a reference to a shared affix.

Const could also mean mutable. This can hence reference the same data as both shared and unshared, which violates the type system.

On 02/12/2016 08:42 PM, Dicebot wrote:
> So you
> envision this kind of metadata support to be only available via specific
> type of allocator, AffixAllocator, and not being supported by most of them?

That is correct. You want metadata, you put an AffixAllocator together. -- Andrei

On 02/12/2016 09:21 PM, Timon Gehr wrote:
> Const could also mean mutable. This can hence reference the same data as
> both shared and unshared, which violates the type system.

If const comes from mutable, then shared is superfluous leading to extra synchronization. That's suboptimal, but how does it violate the type system? -- Andrei

On Saturday, 13 February 2016 at 01:27:49 UTC, Andrei Alexandrescu wrote:
> On 02/12/2016 08:02 PM, tsbockman wrote:
>> What about providing a way to mark a piece of data as thread-local at
>> allocation time?
>
> Yah, could be part of the metadata. Then after inspecting that bit, shared can be casted away. I consider that an optimization that doesn't add or remove generality. -- Andrei

I was actually suggesting encoding the shared-ness into the memory address itself. (No tricks - just allocate shared data in a separate memory range. This may only be feasible on 64-bit though, with its over-abundance of address space.)

This way, you can determine whether the (meta-)data is shared without accessing it at all, just by asking the allocator about the address.

On 02/12/2016 10:03 PM, tsbockman wrote:
> On Saturday, 13 February 2016 at 01:27:49 UTC, Andrei Alexandrescu wrote:
>> On 02/12/2016 08:02 PM, tsbockman wrote:
>>> What about providing a way to mark a piece of data as thread-local at
>>> allocation time?
>>
>> Yah, could be part of the metadata. Then after inspecting that bit,
>> shared can be casted away. I consider that an optimization that
>> doesn't add or remove generality. -- Andrei
>
> I was actually suggesting encoding the shared-ness into the memory
> address itself. (No tricks - just allocate shared data in a separate
> memory range. This may only be feasible on 64-bit though, with its
> over-abundance of address space.)
>
> This way, you can determine whether the (meta-)data is shared without
> accessing it at all, just by asking the allocator about the address.

Yah, TypedAllocator can be used for exactly that. -- Andrei

On Saturday, 13 February 2016 at 03:05:08 UTC, Andrei Alexandrescu wrote:
>> I was actually suggesting encoding the shared-ness into the memory
>> address itself. (No tricks - just allocate shared data in a separate
>> memory range. This may only be feasible on 64-bit though, with its
>> over-abundance of address space.)
>>
>> This way, you can determine whether the (meta-)data is shared without
>> accessing it at all, just by asking the allocator about the address.
>
> Yah, TypedAllocator can be used for exactly that. -- Andrei

Cool. Then this technique could also be used to address Timon Gehr's concerns about violating the type system, if necessary.

On Saturday, 13 February 2016 at 03:03:05 UTC, tsbockman wrote:
> On Saturday, 13 February 2016 at 01:27:49 UTC, Andrei Alexandrescu wrote:
>> On 02/12/2016 08:02 PM, tsbockman wrote:
>>> What about providing a way to mark a piece of data as thread-local at
>>> allocation time?
>>
>> Yah, could be part of the metadata. Then after inspecting that bit, shared can be casted away. I consider that an optimization that doesn't add or remove generality. -- Andrei
>
> I was actually suggesting encoding the shared-ness into the memory address itself. (No tricks - just allocate shared data in a separate memory range. This may only be feasible on 64-bit though, with its over-abundance of address space.)
>
> This way, you can determine whether the (meta-)data is shared without accessing it at all, just by asking the allocator about the address.

Be careful:

https://en.wikipedia.org/wiki/Address_space_layout_randomization

On Saturday, 13 February 2016 at 08:16:04 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 13 February 2016 at 03:03:05 UTC, tsbockman wrote:
>> I was actually suggesting encoding the shared-ness into the memory address itself. (No tricks - just allocate shared data in a separate memory range. This may only be feasible on 64-bit though, with its over-abundance of address space.)
>>
>> This way, you can determine whether the (meta-)data is shared without accessing it at all, just by asking the allocator about the address.
>
> Be careful:
>
> https://en.wikipedia.org/wiki/Address_space_layout_randomization

What issue, specifically, are you trying to point out?

Obviously even with ASL the heap has large contiguous chunks of address space available to it, otherwise it could not allocate large arrays. That is all that is required for my scheme to be workable, I think.