From cfb7ed13e8f042d8ea4fce2c9b053068e17c1f98 Mon Sep 17 00:00:00 2001 From: Justin Ethier Date: Mon, 23 Jul 2018 15:02:13 -0400 Subject: [PATCH] WIP --- docs/Lazy-Sweeping.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/Lazy-Sweeping.md b/docs/Lazy-Sweeping.md index ceb0615d..bdd5bec6 100644 --- a/docs/Lazy-Sweeping.md +++ b/docs/Lazy-Sweeping.md @@ -2,11 +2,11 @@ One of the basic improvements to the mark-sweep algorithm suggested by the Garba With this approach instead of waiting until tracing is finished and having the collector thread sweep the entire heap at once, each thread will sweep its own heaps as part of the allcation. When no more free space is available to meet a request the allocator will check to see if there are unswept heap pages. If so, the next one will be selected, the mutator will sweep it to free up space, and the new page will be used for allocation. If insufficient space is available then a major collection is triggered. -The main goal of this process is to improve performance: +The main goal of this process is to improve performance through: - better locality - heap slots tend to be used after they are swept - thread-local data - there is no need to lock the heap for allocation or sweeping since both operations are now performed by each mutator thread -- accorinding to the GC handbook, it reduces the algorithmic complexity of mark-sweep to be proportional to the size of the live data in the heap, similar to a copying collector +- according to the GC handbook, lazy sweeping reduces the algorithmic complexity of mark-sweep to be proportional to the size of the live data in the heap, similar to a copying collector Older notes: @@ -137,6 +137,7 @@ The existing GC tracked free space and would start a major GC once the amount of # Results TODO: compare performance of new GC to old one, perhaps with benchmarks (compare 0.8.1 release with current 0.9 branch) +Graph benchmarks in the google docs spreadsheet # Conclusion