Note, I am not cc-ing the mailing list.
Two options you might not have considered:
1. Mutator threads and collections threads must be mutually exclusive.
That means that during a stop the world period, or a safe-point
within the game frame, only collection threads run, and after they
are all done, the mutator (i.e. work) threads can continue. This
will still be multi-threaded, and won't have too big of a
performance cost. (This is how we currently do this, though
manually, of course, since there's not much help from C++.)
2. Every object on the heap must be referenced through a forwarding
pointer. This means that all read-only requests are penalized by
double reads, but that is acceptable. The address of the object
should never be allowed to be read. The location of the forwarding
pointer (including its reference count, etc.) must stick around. For
mutation, the forwarding pointer gets (atomically) locked, copied to
a new location (including its mutation), and then updated to the new
location, then finally unlocked. A reading thread will see the old
data, but that's presumably fine.
Have no idea if that helps or not - I am no expert by far. I would think
though that
int a = myObj.mVar;
turning into
dptr = ld(myObj, FORWARDING_OFFSET) ;; myObj points to the
reference object (flags, pointer, ref-count, etc.)
a = ld(dptr, MVAR_OFFSET) ;;
is better than the branch.
PKE
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
