From 4cb17436a67d0b49287ea0f805a6160b3926b3a9 Mon Sep 17 00:00:00 2001 From: Justin Ethier Date: Tue, 27 Oct 2015 23:03:16 -0400 Subject: [PATCH] Added more notes --- gc.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/gc.c b/gc.c index 36a4d3cd..9620775f 100644 --- a/gc.c +++ b/gc.c @@ -434,6 +434,19 @@ any allocations will not be collected. also once collectors go 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 sneak into a stack object during the async phase? + + +more questions: +- 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? + need to be able to prevent this somehow... +- how does the collector handle stack objects that reference objects from + another thread's stack? + ) need to figure this out because do not want to move these early, right? + want its own stack to move them? + ) 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 + at all costs. // void gc_mut_cooperate(gc_thread_data *thd) {