Thread local and memory allocation

[deadalnix]

Le 04/10/2011 02:15, Walter Bright a écrit :
> On 10/3/2011 4:20 PM, Sean Kelly wrote:
>> Immutable data would have to be allocated on the shared heap as well,
>> which
>> means the contention for the shared heap may actually be fairly
>> significant.
>> But the alternatives are all too complex (migrating immutable data
>> from local
>> pools to a common pool when a thread terminates, etc). There's also the
>> problem of transferring knowledge of whether something is immutable
>> into the
>> allocation routine. As things stand, I don't believe that type info is
>> available.
>
> Right. The current language allows no way to determine in advance if an
> allocation will be eventually made immutable (or shared) or not.
>
> However, if the gc used thread local pools to do the allocation from
> (not the collection), the gc would go faster because it wouldn't need
> locking to allocate from those pools. This change can happen without any
> language or compiler changes.

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.

This is a good solution do reduce contention on allocation. But a very 
different thing than I was initially talking about.

*******

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 ?