On Tue, 04 Oct 2011 23:56:52 -0400, Andrew Wiley <wiley.andre...@gmail.com>
wrote:
On Tue, Oct 4, 2011 at 10:55 PM, Andrew Wiley <wiley.andre...@gmail.com> wrote:
On Tue, Oct 4, 2011 at 8:59 PM, Robert Jacques <sandf...@jhu.edu> wrote:
On Tue, 04 Oct 2011 10:54:58 -0400, Andrew Wiley <wiley.andre...@gmail.com>
wrote:
On Tue, Oct 4, 2011 at 3:52 AM, Walter Bright
<newshou...@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.
If you meant that the *user* should be responsible for making sure
it's allocated on the shared heap, then yes, that's possible, but
you're putting GC implementation details into the type system. That
may or may not be a good thing.
I would phrase it as a shift D's memory model towards NUMA. By the way, GP GPU
is here to stay and it's NUMA. HPC software is cache aware, which is NUMA. And
all high-end server systems are NUMA aware, to say nothing of cluster/fabric
computing.
