Go公式の「A Guide to the Go Garbage Collector」を理解するために

https://go.dev/doc/gc-guide
このドキュメントを理解したい。

Introduction

Note that the existence of a garbage collector as described by this guide is not guaranteed by the Go specification, only that the underlying storage for Go values is managed by the language itself. This omission is intentional and enables the use of radically different memory management techniques.

• GoのGCはGoの仕様で保証されているものではなくて、Goのストレージの基礎となる値はGo言語それ自体によって管理されている。←どういうこと？
• この省略は、意図的で、根本的に異なるメモリ管理技術の使用を可能にする？？

Therefore, this guide is about a specific implementation of the Go programming language and may not apply to other implementations. Specifically, this following guide applies to the standard toolchain (the gc Go compiler and tools). Gccgo and Gollvm both use a very similar GC implementation so many of the same concepts apply, but details may vary.

• このガイドはGoの実装の特定の実装に関するもの。
• GoのGCは、GccgoとGollvmのどちらにもよく似たGCの実装を使用している。

Where Go Values Live

• GCのことについて話す前にGCで管理される必要がないメモリについて話すぜって感じのところ
• ローカル変数に格納されたポインタではない値は、GCによって管理されない可能性が高い。代わりに、lexical scope に関連づけられたメモリが作成されるようにする。
• このようにメモリを確保することを「スタックアロケーション」と呼びますが、これはその領域がgoroutineスタックに格納されるから。
• Goコンパイラがそのライフタイムを判断できないため、この方法でメモリを確保できないGoの値は、ヒープにエスケープされる。
• ヒープに割り当てられることは、 "dynamic memory allocation"と言われる。
• なぜならコンパイラとラインタイムは、メモリがどのように使用され、いつクリーンアップされるか仮定できないから。
• GCは、 "dynamic memory allocation"を明確に識別し、クリーンアップするシステム。
• ヒープにエスケープされる理由の一つは、そのサイズが動的に決まるから。
• ヒープにエスケープされことはまた、推移的でなければならない。
• あるGoの値への参照がエスケープされることが決まっている別の値に書き込まれると、その値もエスケープされる。
• Goの値がエスケープされるかどうかは、その値が使用されるコンテキストとGoコンパイラのエスケープ分析アルゴリズムによるもの。