Thread local and memory allocation
deadalnix at gmail.com
Tue Oct 4 01:22:23 PDT 2011
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,
>> means the contention for the shared heap may actually be fairly
>> 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
> 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
What is the issue with the compiler here ?
More information about the Digitalmars-d