| commit | 84441239076b6a9a6a04381b62e7904f7325ebc0 | [log] [tgz] |
|---|---|---|
| author | janakr <janakr@google.com> | Tue Mar 03 07:32:28 2020 -0800 |
| committer | Copybara-Service <copybara-worker@google.com> | Tue Mar 03 07:33:34 2020 -0800 |
| tree | dcd32ceb3625c94283ca1d9c5a160294688c6c7d | |
| parent | 858a4b1a44f1058f5bbec9ea778421038ef34f10 [diff] |
If a TreeFileArtifact is not explicitly in ActionExecutionValue's metadata map, check its TreeArtifactValue cache and return a value if it's there. Much of the time, a TreeFileArtifact's metadata will be in the main map: if it was the output of a templated action, it will be in the main map. It will also be there if it was explicitly statted/injected, either from Google-internal remote execution or as part of local execution. However, if the tree artifact was injected via ActionMetadataHandler#injectRemoteDirectory, it is not present in the main metadata map. I considered two other options for this CL: (1) Explicitly add TreeFileArtifact metadata in ActionMetadataHandler#injectRemoteDirectory. Leads to increased memory usage for tree artifacts with Bazel remote execution (though just on parity with Google-internal/local) and maintains this as a sharp edge that could lead to crashes in the future if another use case is added. (2) Explicitly add TreeFileArtifact metadata inside OutputStore#putTreeArtifactData. Duplicates work for local/Google-internal remote execution, where the metadata was already added, and has memory disadvantage. This change seemed better: it makes explicit that TreeFileArtifacts don't have to be added, and saves a bit of memory at the cost of three map lookups instead of one for TreeFileArtifacts with Bazel remote execution. If Google-internal remote execution supported directories natively, we would move in this direction there as well. PiperOrigin-RevId: 298601895
{Fast, Correct} - Choose two
Build and test software of any size, quickly and reliably.
Speed up your builds and tests: Bazel rebuilds only what is necessary. With advanced local and distributed caching, optimized dependency analysis and parallel execution, you get fast and incremental builds.
One tool, multiple languages: Build and test Java, C++, Android, iOS, Go, and a wide variety of other language platforms. Bazel runs on Windows, macOS, and Linux.
Scalable: Bazel helps you scale your organization, codebase, and continuous integration solution. It handles codebases of any size, in multiple repositories or a huge monorepo.
Extensible to your needs: Easily add support for new languages and platforms with Bazel's familiar extension language. Share and re-use language rules written by the growing Bazel community.
Follow our tutorials:
See CONTRIBUTING.md
