Update MEMORY-MANAGEMENT.md (#129)

Andreu and I talked with some colleagues whose day-to-day job is to work on garbage collectors, and they gave us recommendations on how it would be best to implement the weakness of async context maps balancing memory usage and GC performance.

Co-authored-by: Chengzhong Wu <[email protected]>

Author: nicolo-ribaudo

MEMORY-MANAGEMENT.md

@@ -84,36 +84,53 @@ references) because you can do `asyncVar.get()` inside that context and get the
 associated value, even if there are no other references to it.
 
 However, the AsyncContext proposal purposefully gives JS code no way to get a
-list of the entries, or the `AsyncContext.Variable` keys, in a context. This is
+list of the entries stored in an async context map. This is
 done to maintain encapsulation, but it also has the side effect that it allows
 implementing the context as a weak map.
 
-If an `AsyncContext.Variable` key in the context could be GC'd other than
-because it's a key in the context, then there is no way for any JS code to be
-able to access that key at any future time. At that point, that whole entry in
-the context, including its value, could be deleted (or all references could be
-made weak). This would be implementing the context as a weak map (see the JS
-[`WeakMap`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WeakMap)
+If an `AsyncContext.Variable` used as a key in the context is otherwise unreachable,
+then there is no way for any JS code to read the corresponding async context entry
+at any future time. At that point, that whole entry in the context map (both the key
+and the value), could be deleted. This would be implementing the context as a weak
+map (see the JS [`WeakMap`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WeakMap)
 built-in).
 
 In most uses of AsyncContext, we don't expect that `AsyncContext.Variable`s
-could become unreachable (i.e. GC-able) while the realm in which it was created
-remains alive. This is because most uses would store it in a (JavaScript)
-variable at the top level of a script or module, so any exported functions in
-the script/module will have it in its scope, and will keep it alive.
+could become unreachable (i.e. GC-able) while the async context maps that capture
+stay reachable. This is because most uses would store the `AsyncContext.Variable`
+object in a (JavaScript) variable at the top level of a script or module, so any
+exported functions in the script/module will have it in its scope, and will keep
+it alive.
 
 However, we do expect a weak map implementation to be useful in cases where a
-cross-realm interaction results in `AsyncContext.Variable` keys and object
-values of different realms in the same context, since otherwise that could
-result in leaking the realm. After all, we expect that in the general case
-`AsyncContext.Variable` keys from a realm would map to values that only contain
-objects from the same realm. So if the only remaining references to a realm are
-from entries in the context which have keys in the realm, the keys will be
-unreachable, and so the entries will be deleted.
+cross-realm interaction results in capturing `AsyncContext.Variable` keys from a different realm. This capturing happens implicitly through cross-realm function
+calls, and we wouldn't want to accidentally keep a whole realm alive.
 
 The proposed JS spec for AsyncContext does not explicitly mandate that the
 context must be implemented as a weak map, but that is a possible
-implementation. However, garbage collecting weak maps takes a performance hit,
-and some folks have previously argued against it for that reason. If you think
-it's important that the context is a weak map, please let us know so we can
-discuss it with the various JS engine implementers.
+implementation. However, we are aware that garbage collecting weak maps comes at a
+performance cost.
+
+We expect that there will be two "kinds" of async context maps:
+- a lot of very short-lived ones, used by frameworks during the rendering process.
+- a few long-lived ones, used to trace long-running tasks
+
+We also expect that, while there can be a lot of async context maps, they will all contain a very limited number of entries (a single-digit amount in most cases).
+
+For this reason, after consulting with experts in the field, the champions'
+recommendation is to implement a hybrid approach. Async context maps should initially
+be considered to held their entries strongly, and then transition to be weak after a
+while. Deciding exactly what "after a while" means will need in-the-field
+experimentation, but some potential approaches are:
+- async context maps that survive one major CG cycle get marked as weak
+  - or, async context maps that survive X major GC cycles
+- async context maps are marked as weak after a set amount of time
+- for platform that have "young objects" and "old objects" memory spaces, async context maps could become weak once they get moved to the old space.
+
+The goal of these approaches is that when creating async context maps that live
+shorter than a framework's rendering cycle, they would never transition to be
+weak before that the whole map is garbage collected.
+
+Given that weak context maps are not directly exposed to JavaScript, switching between
+weak and strong only requires flipping a bit somewhere that the garbage collector
+references graph traversal logic can check.