-
Notifications
You must be signed in to change notification settings - Fork 4.1k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Move signaledDeps to DirtyBuildingState
This requires using DirtyBuildingState also for the initial evaluation of a node. As a side effect, this reduces the set of possible states, which might make it easier to reason about the state. States: previously, NodeEntry distinguished between initial evaluation and incremental update, with 2 different states (just created / marked and evaluating) for each case. With this change, the case distinction goes away. This subtly changes the semantics of isDirty(): previously, isDirty returned false for new nodes; now it returns true for new nodes after their computation is triggered. This change should reduce memory consumption of InMemoryNodeEntry objects per instance for nodes that are done, but at the expense of additional temporary DirtyBuildingState instances for nodes that are not done. I am making this change in preparation for adding another field to the dirty state, which would otherwise increase memory consumption of all done nodes. = Memory consumption While this decreases the memory consumption of Skyframe nodes in the done state, it also increases the memory consumption of Skyframe nodes that have to be recomputed, especially for new nodes, but also for incrementally updated nodes. New nodes now have to allocate a DirtyBuildingState instance while they are in-flight, and incrementally updated nodes now have an additional field in the DirtyBuildingState. For incrementally updated nodes, the difference is a wash - we save some in InMemoryNodeEntry and lose the same amount in DirtyBuildingState. For clean builds, whether or not this is a reduction in memory use depends on the ratio of in-flight to done nodes. The higher the ratio, the higher the memory consumption. Note that the ratio goes to zero at the end of a build, so this is a strict win for memory consumption at rest (i.e., between builds), and only a concern while Bazel is active. For some representative target, I saw ratios of less than 25% at max during the loading+analysis phase, and dropping off sharply as packages were completed. During the execution phase, the ratio only barely got above 10% and usually stayed below 5%. Assuming a memory difference of 8 bytes per done node (since the Jvm performs 8-byte alignment), and an increase of 24 bytes per in-flight node, any ratio below 1/3 is a net win for post-gc memory consumption, although at the cost of slightly higher gc pressure. This is clearly the case from the numbers I collected. For incremental builds, the number of invalidated and recomputed nodes is usually much, much lower (I saw numbers as low as 0.02%), which virtually guarantees that this change is a net win. PiperOrigin-RevId: 233899818
- Loading branch information
Showing
7 changed files
with
211 additions
and
136 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.