You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Back in 0.4.x and earlier, SpawnActions created by ctx.action always had an empty runfiles supplier. At some point—I think 4a87738—, such SpawnActions started having non-empty runfiles suppliers. As ActionExecutionFunctiondutifully declares deps on all action inputs and runfiles supplier artifacts, one of the major reasons for runfiles middleman is defeated. This hits actions that have tools with many runfiles hard. In one large build I have, this bug increased the total number of skyframe edges by 10x (1.6 million to 17 million) leading to a major memory (and GC time) regression.
The simplest solution is to not depend on runfiles artifacts in ActionExecutionFunction. I.e.,
This appears to fix the problem. It also mostly passes tests; however, remote execution requires runfiles to be in the PerActionFileCache. I'm not sure if there's a good way around this. (Can we treat the runfiles middleman as an aggregating middleman and pull the transitive ArtifactValues through as this comment suggests?)
The text was updated successfully, but these errors were encountered:
The goal is to, for an action execution, make only a single skyframe
edge to every required runfiles tree rather than an edge to every
runfiles artifact directly. We accomplish this by pulling the runfiles
artifacts' metadata for a particular runfiles tree through the
appropriate runfiles middlemen artifact in one batch. This CL fixesbazelbuild/bazel#3217.
This change makes runfiles middlemen more similar to aggregating
middlemen. We however continue to treat runfiles middlemen slightly
differently than true aggregating middlemen. Namely, we do not expand
runfiles middlemen into the final action inputs. The reasons for this
are:
1. It can make latent bugs like
bazelbuild/bazel#4033 more severe.
2. The runfiles tree builder action's output MANIFEST contains
absolute paths, which interferes with remote execution if its metadata
is added to a cache hash.
3. In the sandbox, it causes the runfiles artifacts to be mounted at
their exec path locations in addition to within the runfiles
trees. This makes the sandbox less strict. (Perhaps tolerably?)
4. It saves a modicum of (transient) memory and time to not expand.
If the first two issues are fixed, it could be a nice simplification
to completely replace runfiles middlemen with aggregating middlemen.
Change-Id: I2d2148297f897af4c4c6dc055d87f8a6fad0061e
PiperOrigin-RevId: 198307109
Back in 0.4.x and earlier,
SpawnAction
s created byctx.action
always had an empty runfiles supplier. At some point—I think 4a87738—, suchSpawnAction
s started having non-empty runfiles suppliers. AsActionExecutionFunction
dutifully declares deps on all action inputs and runfiles supplier artifacts, one of the major reasons for runfiles middleman is defeated. This hits actions that have tools with many runfiles hard. In one large build I have, this bug increased the total number of skyframe edges by 10x (1.6 million to 17 million) leading to a major memory (and GC time) regression.The simplest solution is to not depend on runfiles artifacts in
ActionExecutionFunction
. I.e.,This appears to fix the problem. It also mostly passes tests; however, remote execution requires runfiles to be in the
PerActionFileCache
. I'm not sure if there's a good way around this. (Can we treat the runfiles middleman as an aggregating middleman and pull the transitiveArtifactValue
s through as this comment suggests?)The text was updated successfully, but these errors were encountered: