Added notes

This commit is contained in:
Justin Ethier 2015-10-28 18:53:15 -04:00
parent 4cb17436a6
commit 22fe970b4a

43
gc.c
View file

@ -410,10 +410,12 @@ void gc_mut_update()
// Done as part of gc_move // Done as part of gc_move
//void gc_mut_create() //void gc_mut_create()
// /*
TODO: think these points through and get answers from the paper TODO: think these points through and get answers from the paper
before writing the code: before writing the code:
PHASE 1 - separation of mutator and collector into separate threads
can cooperate be part of a minor gc? in that case, the can cooperate be part of a minor gc? in that case, the
marking could be done as part of allocation marking could be done as part of allocation
@ -435,19 +437,44 @@ async they have a chance to markgray, which will include the write
barrier. so given that, is it still possible for an old heap ref to barrier. so given that, is it still possible for an old heap ref to
sneak into a stack object during the async phase? sneak into a stack object during the async phase?
more questions on above point:
more questions: - figure out how/if after cooperation/async, can a stack object pick
- from above, figure out how/if after cooperation/async, can a stack object pick
up a reference to a heap object that will be collected during that GC cycle? up a reference to a heap object that will be collected during that GC cycle?
need to be able to prevent this somehow... need to be able to prevent this somehow...
- need to figure out real world use case(s) where this could happen, to try and
figure out how to address this problem
PHASE 2 - multi-threaded mutator (IE, more than one stack thread):
- how does the collector handle stack objects that reference objects from - how does the collector handle stack objects that reference objects from
another thread's stack? another thread's stack?
) need to figure this out because do not want to move these early, right? * minor GC will only relocate that thread's objects, so another thread's would not
want its own stack to move them? be moved. however, if another thread references one of the GC'd thread's
) but does that mean we need a fwd pointer to be live for awhile? do we need stack objects, it will now get a forwarding pointer. even worse, what if the
other thread is blocked and the reference becomes corrupt due to the stack
longjmp? there are major issues with one thread referencing another thread's
objects.
* had considered adding a stack bit to the object header. if we do this and
initialize it during object creation, a thread could in theory detect
if an object belongs to another thread. but it might be expensive because
a read barrier would have to be used to check the object's stack bit and
address (to see if it is on this heap).
* alternatively, how would one thread pick up a reference to another one's
objects? are there any ways to detect these events and deal with them?
it might be possible to detect such a case and allocate the object on the heap,
replacing it with a fwd pointer. unfortunately that means we need a read
barrier (ick) to handle forwarding pointers in arbitrary places
* but does that mean we need a fwd pointer to be live for awhile? do we need
a read barrier to get this to work? obviously we want to avoid a read barrier a read barrier to get this to work? obviously we want to avoid a read barrier
at all costs. at all costs.
// - what are the real costs of allowing forwarding pointers to exist outside of just
minor GC? assume each runtime primitive would need to be updated to handle the
case where the obj is a fwd pointer - is it just a matter of each function
detecting this and (possibly) calling itself again with the 'real' address?
obviously that makes the runtime slower due to more checks, but maybe it is
not *so* bad?
*/
void gc_mut_cooperate(gc_thread_data *thd) void gc_mut_cooperate(gc_thread_data *thd)
{ {
if (thd->gc_mut_status == gc_status_col) { // TODO: synchronization of var access if (thd->gc_mut_status == gc_status_col) { // TODO: synchronization of var access