Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

spawn action execution directly depends on runfiles artifacts #3217

Closed
benjaminp opened this issue Jun 19, 2017 · 2 comments
Closed

spawn action execution directly depends on runfiles artifacts #3217

benjaminp opened this issue Jun 19, 2017 · 2 comments
Assignees
Labels
P2 We'll consider working on this in future. (Assignee optional) type: bug

Comments

@benjaminp
Copy link
Collaborator

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 ActionExecutionFunction 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.,

diff --git a/src/main/java/com/google/devtools/build/lib/skyframe/ActionExecutionFunction.java b/src/main/java/com/google/devtools/build/lib/skyframe/ActionExecutionFunction.java
index 1b4bb2950..70c7ffe4b 100644
--- a/src/main/java/com/google/devtools/build/lib/skyframe/ActionExecutionFunction.java
+++ b/src/main/java/com/google/devtools/build/lib/skyframe/ActionExecutionFunction.java
@@ -231,8 +231,7 @@ public class ActionExecutionFunction implements SkyFunction, CompletionReceiver
   @Nullable
   private AllInputs collectInputs(Action action, Environment env)
       throws ActionExecutionFunctionException, InterruptedException {
-    Iterable<Artifact> allKnownInputs = Iterables.concat(
-        action.getInputs(), action.getRunfilesSupplier().getArtifacts());
+    Iterable<Artifact> allKnownInputs = action.getInputs();
     if (action.inputsDiscovered()) {
       return new AllInputs(allKnownInputs);
     }

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?)

@philwo philwo added P2 We'll consider working on this in future. (Assignee optional) type: bug labels Jun 21, 2017
@philwo
Copy link
Member

philwo commented Jun 21, 2017

This seems like an area that @ulfjack might know something about.

@ulfjack
Copy link
Contributor

ulfjack commented Jun 26, 2017

@tomlu FYI

I don't have any immediate ideas on how to improve this. Maybe we need to do some special support in Skyframe?

luca-digrazia pushed a commit to luca-digrazia/DatasetCommitsDiffSearch that referenced this issue Sep 4, 2022
    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 fixes
    bazelbuild/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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P2 We'll consider working on this in future. (Assignee optional) type: bug
Projects
None yet
Development

No branches or pull requests

4 participants