Mention `SkyKeyComputeState` in `CODEBASE.md`.

PiperOrigin-RevId: 419868323

CODEBASE.md

diff --git a/CODEBASE.md b/CODEBASE.md
index 9cbee1d..6f9a2ba 100644
--- a/CODEBASE.md
+++ b/CODEBASE.md
@@ -379,7 +379,14 @@
 
 A consequence of this is that if not all dependencies are available in (3), the
 function needs to be completely restarted and thus computation needs to be
-re-done. This is obviously inefficient. We work around this in a number of ways:
+re-done, which is obviously inefficient. `SkyFunction.Environment.getState()`
+lets us directly work around this issue by having Skyframe maintain the
+`SkyKeyComputeState` instance between calls to `SkyFunction.compute` for the
+same `SkyKey`. Check out the example in the javadoc for
+`SkyFunction.Environment.getState()`, as well as real usages in the Bazel
+codebase.
+
+Other indirect workarounds:
 
 1.  Declaring dependencies of `SkyFunction`s in groups so that if a function
     has, say, 10 dependencies, it only needs to restart once instead of ten
@@ -387,12 +394,8 @@
 2.  Splitting `SkyFunction`s so that one function does not need to be restarted
     many times. This has the side effect of interning data into Skyframe that
     may be internal to the `SkyFunction`, thus increasing memory use.
-3.  Using caches "behind the back of Skyframe" to keep state (e.g. the state of
-    actions being executed in `ActionExecutionFunction.stateMap` . In the
-    extreme, this ends up resulting in writing code in continuation-passing
-    style (e.g. action execution), which does not help readability.
 
-Of course, these are all just workarounds for the limitations of Skyframe, which
+These are all just workarounds for the limitations of Skyframe, which
 is mostly a consequence of the fact that Java doesn't support lightweight
 threads and that we routinely have hundreds of thousands of in-flight Skyframe
 nodes.