Discuss GC pauses

pep-0556.rst

@@ -350,8 +350,8 @@ in deterministic visible behaviour anyway.  Second because the GC deals
 with reference cycles while many objects are reclaimed immediately when their
 last visible reference disappears.
 
-Impact on performance
----------------------
+Impact on CPU consumption
+-------------------------
 
 The pseudo-code above adds two lock operations for each implicit collection
 request in "threaded" mode: one in the thread making the request (a
@@ -368,6 +368,19 @@ speculation and superscalar execution).
 Actual measurements on worst-case mini-benchmarks may help provide
 reassuring upper bounds.
 
+Impact on GC pauses
+-------------------
+
+While this PEP does not concern itself with GC pauses, there is a
+practical chance that releasing the GIL at some point during an implicit
+collection (for example by virtue of executing a pure Python finalizer)
+will allow application code to run in-between, lowering the *visible* GC
+pause time for some applications.
+
+If this PEP is accepted, future work may try to better realize this potential
+by speculatively releasing the GIL during collections, though it is unclear
+how doable that is.
+
 
 Open issues
 ===========