From ae3ba3cd1ac3c478864e84ff90bdb87f2f575d02 Mon Sep 17 00:00:00 2001 From: Justin Ethier Date: Thu, 12 Nov 2015 22:49:51 -0500 Subject: [PATCH] Added notes regarding update() --- gc.c | 27 ++++++++++++++++++++++----- 1 file changed, 22 insertions(+), 5 deletions(-) diff --git a/gc.c b/gc.c index a35e8554..db39b460 100644 --- a/gc.c +++ b/gc.c @@ -504,15 +504,32 @@ PHASE 2 - multi-threaded mutator (IE, more than one stack thread): ///////////////////////////////////////////// // GC functions called by the Mutator threads -void gc_mut_update() +void gc_mut_update(object heapO) { // TODO: how does this fit in with the write buffer? // this part is important, especially during tracing -} -// Done as part of gc_move -// ideally want to do this without needing sync. we need to sync to get markColor in coop, though -//void gc_mut_create() + the paper marks both the heap location being written to and the + value being written. not sure it makes sense to mark the value + as it will always be on the stack - issue is if any obj's it is + referencing are on the heap. this is where that stack bit might + come in handy. + + do we want to mark gray immediately during add mutator, or wait + until minor GC? YES - I think for mutators we need to mark the + object gray immediately. otherwise if we delay until GC, a sweep + may have already finished up and freed such an obj that would + otherwise not have been freed if we had waited. + + again, only potential issue seems to be if a stack obj could ref + something else on the heap - can that happen? I think this can only + happen if the heap obj it refs is linked to a root, because stack + objs are so short lived?? + + also we already know if objects are on the stack due to their color (RED). + so can use this to not mark red values. otherwise probably do want + to mark the 'y' as well (per paper) to prevent timing issues when we wait +} // TODO: still need to handle case where a mutator is blocked void gc_mut_cooperate(gc_thread_data *thd)