From 057c40eba8239d804eb9bb5c8f2e1cad1e3a1b6d Mon Sep 17 00:00:00 2001 From: Justin Ethier Date: Wed, 14 Oct 2015 23:15:58 -0400 Subject: [PATCH] Added more notes --- gc-notes.txt | 2 ++ runtime.c | 8 ++++++++ 2 files changed, 10 insertions(+) create mode 100644 gc-notes.txt diff --git a/gc-notes.txt b/gc-notes.txt new file mode 100644 index 00000000..c704c36b --- /dev/null +++ b/gc-notes.txt @@ -0,0 +1,2 @@ +Phase 1 (gc-dev) - Add gc.h, make sure it compiles. +Phase 2 (gc-dev2) - Change how strings are allocated, to clean up the code and be compatible with a new GC algorithm. diff --git a/runtime.c b/runtime.c index b957465b..deb7260d 100644 --- a/runtime.c +++ b/runtime.c @@ -2420,6 +2420,14 @@ to handle this detail yet. and it is very important to get right thoughts: - worth having a write barrier for globals? that is, only GC those that were modified. just an idea... + - KEEP IN MIND AN OVERALL GOAL, that this should try to be as close as + possible to the cheney algorithm in terms of performance. so obviously we + want to try and do as little work as necessary during each minor GC. + since we will use a write barrier to keep track of the heap's stack refs, + it seems reasonable that we could skip globals that live on the heap. + - To some extent, it should be possible to test changes that improve performance + by coding something inefficient (but guaranteed to work) and then modifying it to + be more efficient (but not quite sure if idea will work). */ longjmp(jmp_main,1); /* Return globals gc_cont, gc_ans. */ }