From cfb671bee4f04447172924fd6cd95cb32497dd7b Mon Sep 17 00:00:00 2001 From: "Michael@WCD" Date: Fri, 18 Sep 2026 00:05:22 -0400 Subject: [PATCH] gh-157724: Fix garbage collector documentation typos --- InternalDocs/garbage_collector.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/InternalDocs/garbage_collector.md b/InternalDocs/garbage_collector.md index 0ef45ff8e02bc5f..d7d867e626a1418 100644 --- a/InternalDocs/garbage_collector.md +++ b/InternalDocs/garbage_collector.md @@ -448,7 +448,7 @@ collections (that is, collections of the young and middle generations) will alwa examine roughly the same number of objects (determined by the aforementioned thresholds) the cost of a full collection is proportional to the total number of long-lived objects, which is virtually unbounded. Indeed, it has -been remarked that doing a full collection every of object +been remarked that doing a full collection after a fixed number of object creations entails a dramatic performance degradation in workloads which consist of creating and storing lots of long-lived objects (for example, building a large list of GC-tracked objects would show quadratic performance, instead of linear as @@ -533,7 +533,7 @@ into the cache. This is the mechanism that provides the window. When performing the transitive closure of "alive" status, the set of objects yet to visit are stored in one of two places. First, they can be stored in the -prefech buffer. Second, there is a LIFO stack, of unlimited size. When object +prefetch buffer. Second, there is a LIFO stack, of unlimited size. When object references are found using `tp_traverse`, they are enqueued in the buffer if it is not full, otherwise they are pushed to the stack. @@ -616,7 +616,7 @@ This optimization, as of March 2025, was tuned on the following hardware platforms: - Apple M3 Pro, 32 GB RAM, 192+128 KB L1, 16 MB L2, compiled with Clang 19 -- AMD Ryzen 5 7600X, 64 GB RAM, 384 KB L1, 6 GB L2, 32 MB L3, compiled with GCC 12.2.0 +- AMD Ryzen 5 7600X, 64 GB RAM, 384 KB L1, 6 MB L2, 32 MB L3, compiled with GCC 12.2.0 Benchmarking the effectiveness of this optimization is particularly difficult. It depends both on hardware details, like CPU cache sizes and memory latencies,