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 ?
