Thread local and memory allocation

[Robert Jacques]

On Tue, 04 Oct 2011 23:55:19 -0400, Andrew Wiley <wiley.andrew.j at gmail.com> wrote:

> On Tue, Oct 4, 2011 at 8:59 PM, Robert Jacques <sandford at jhu.edu> wrote:
>> On Tue, 04 Oct 2011 10:54:58 -0400, Andrew Wiley <wiley.andrew.j at gmail.com>
>> wrote:
>>
>>> On Tue, Oct 4, 2011 at 3:52 AM, Walter Bright
>>> <newshound2 at digitalmars.com> wrote:
>>>>
>>>> On 10/4/2011 1:22 AM, deadalnix wrote:
>>>>>
>>>>> Do you mean manage the memory that way :
>>>>> Shared heap -> TL pool within the shared heap -> allocation in thread
>>>>> from
>>>>> TL pool.
>>>>>
>>>>> And complete GC collect.
>>>>
>>>> Yes.
>>>>
>>>>
>>>>> This is a good solution do reduce contention on allocation. But a very
>>>>> different
>>>>> thing than I was initially talking about.
>>>>
>>>> Yes.
>>>>
>>>>
>>>>> Back to the point,
>>>>>
>>>>> Considering you have pointer to immutable from any dataset, but not the
>>>>> other
>>>>> way around, this is also valid to get a flag for it in the allocation
>>>>> interface.
>>>>>
>>>>> What is the issue with the compiler here ?
>>>>
>>>> Allocate an object, then cast it to immutable, and pass it to another
>>>> thread.
>>>>
>>>
>>> Assuming we have to make a call to the GC when an object toggles its
>>> immutable/shared state, it seems like this whole approach would
>>> basically murder anyone doing message passing with ownership changes,
>>> because the workflow tends to be create an object -> cast to shared ->
>>> send to another thread -> cast away shared -> do work -> cast to
>>> shared...
>>> On the other hand, I guess the counterargument is that locking an
>>> uncontended lock is on the order of two instructions (or so I'm told),
>>> so casting away shared probably isn't ever necessary. It just seems
>>> somewhat counterintuitive that casting to and from shared would be
>>> slower than unnecessarily locking the object.
>>>
>>
>> It's entirely possible to simply allocate the memory for the object from the
>> shared heap to start with. Then no more calls to the GC are needed.
>>
>
> When an object is created and later cast to shared, the compiler
> *can't* know that it should allocate from the shared heap because the
> cast may not be anywhere near where the object was created. The same
> problem goes for immutable.
>

But that not the scenario being discussed. In fact, having a dangling reference, and therefore having an object mutate under you, is just as dangerous as having the GC re-use a memory block. And honestly, as a GC clear or re-use is likely to segfault early and often, its a very detectable bug. Besides, anyone attempting to do this is going to be actively managing references and/or making this a library implementation detail. In fact, they're probably using going to use unqiue!T, which would always allocate from the correct heap.