On Tue, 04 Oct 2011 23:55:19 -0400, 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.
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.
