commit 3180218123f36dd71afecf3d944c7d1b3123c316
author Nate Biggs <natebiggs@google.com> Fri Aug 25 18:21:37 2023 +0000
committer Commit Queue <dart-scoped@luci-project-accounts.iam.gserviceaccount.com> Fri Aug 25 18:21:37 2023 +0000
tree 3ca3f3af539357a28cb54ff6133166d8965433e6
parent 3d49eec99106c00b031f66d3c403a343ef92b237

[dart2js] Defer bodies of Dart members in JS AST.

Today we deserialize and hold the entirety of the JS AST in memory for the duration of the linker phase. This phase is the most memory intensive, especially when you account for the overhead of the serialized bytes themselves.

This change allows us to deserialize the bodies of JS code generated from Dart members on demand rather than eagerly.

On its own this would incur some overhead as we walk the JS AST many times while finalizing and emitting code. However, most of these visitors are just finding and replacing deferred expressions (i.e. linking). To avoid the extra full traversals of the AST (and the associated cost of deserialization), we can instead keep references directly to the deferred expressions (using the deserialization caching index) and limit the traversals to those specific parts of the AST.

This does incur some additional overhead in serialization size but only on the order of 10s of MBs for a 300+MB file.

After all these changes the emitter phase (3b) appears to be equally fast (if not very slightly faster) and uses ~1GB less memory. These same results hold for builds on large apps built on internal infrastructure.

Note: This has no noticeable effect on combined codegen/emitter (phase 3) as the generated AST will not contain any `NodeWithDeferredExpressionData` so we will just walk the AST to find the relevant nodes as before.

Change-Id: I4f55bbc6543cff332b30878484cbce9eb10c98d1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/322162
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Stephen Adams <sra@google.com>