From b50505c5c2e8064d3a7b79d21f54704aa4dcccac Mon Sep 17 00:00:00 2001 From: Justin Ethier Date: Wed, 30 Nov 2022 15:19:32 -0500 Subject: [PATCH] Update Garbage-Collector-Revised-2022.md --- docs/Garbage-Collector-Revised-2022.md | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/docs/Garbage-Collector-Revised-2022.md b/docs/Garbage-Collector-Revised-2022.md index 60505e45..af7f80f3 100644 --- a/docs/Garbage-Collector-Revised-2022.md +++ b/docs/Garbage-Collector-Revised-2022.md @@ -310,7 +310,7 @@ The collector finds all live objects using a breadth-first search and marks them Initial object graph -The collector thread performs the bulk of its work during this phase. For more details see the [Collector Thread](#collector-thread) section. +The collector thread performs the bulk of its work during this phase. For more details see the [Collector Trace](#collector-trace) section. ### Sweep This function is included here for completeness but is actually performed much later due to [lazy sweeping](#lazy-sweeping). @@ -448,6 +448,12 @@ This function performs tracing for the collector by looping over all of the muta empty_collector_mark_stack() m->last_read++ +The primary job of the collector thread is tracing. + +While tracing the collector visits all live objects and marks them as being in use. Since these objects are stored all across the heap the tracing algorithm cannot take advantage of object locality and tends to demonstrate unusual memory access patterns, leading to inefficient use of the processor cache and poor performance. This makes tracing an excellent task to be done in parallel with the mutator threads so it does not slow down application code. + +Note that during tracing some synchronization is required between the collector and the mutator threads. When an object is changed (EG via: `set!`, `vector-set!`, etc) the mutator needs to add this object to the mark stack, which requires a mutex lock to safely update shared resources. + ## Cooperation by the Collector In practice a mutator will not always be able to cooperate in a timely manner. For example, a thread can block indefinitely waiting for user input or reading from a network port. In the meantime the collector will never be able to complete a handshake with this mutator and major GC will never be performed. @@ -474,14 +480,6 @@ Cyclone checks the amount of free memory as part of its cooperation code. A majo The goal is to run major collections infrequently while at the same time minimizing the allocation of new heap pages. -### Collector Thread - -As well as coordinating major GC the main job of the collector thread is tracing. - -During this phase the collector visits all live objects and marks them as being in use. Since these objects are stored all across the heap the tracing algorithm cannot take advantage of object locality and tends to demonstrate unusual memory access patterns, leading to inefficient use of the processor cache and poor performance. This makes tracing an excellent task to be done in parallel with the mutator threads so it does not slow down application code. - -Note that during tracing some synchronization is required between the collector and the mutator threads. When an object is changed (EG via: `set!`, `vector-set!`, etc) the mutator needs to add this object to the mark stack, which requires a mutex lock to safely update shared resources. - # Performance Measurements A [benchmark suite](#further-reading) was used to compare performance between the previous version of Cyclone (0.8.1) and the new version with lazy sweeping.