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.
