| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
--
PiperOrigin-RevId: 148342788
MOS_MIGRATED_REVID=148342788
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--experimental_dynamic_configs=off - don't use dynamic configs
--experimental_dynamic_configs=on - use dynamic configs with trimmed fragments
--experimental_dynamic_configs=notrim - use dynamic configs with all fragments
This lets us decouple two independent dimensions of dynamic configurations: 1) being able to trigger new configurations and transitions anywhere and 2) only including the fragments needed by a target's transitive closure.
2) is likely to take much more time and effort to properly finesse (three notable challenges: late-bound attributes, aspects, and dynamic shedding of output path names). But 1) by itself already yields significant benefits. So in the name of starting to shift the config work from backend theory to stuff real builds actually use, this change lets us focus on productionizing 1) without blocking on getting all of 2) working first.
tl;dr: iterable deployment and all that.
--
MOS_MIGRATED_REVID=133874661
|
| |
|
|
|
|
|
| |
The only place we now don't handle InterruptedException is in the action graph created after analysis, since I'm not sure that will be around for that much longer.
--
MOS_MIGRATED_REVID=130327770
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OrderedSetMultimap. This maintains insertion order while eliminating duplicates.
Certain rules, in particular, otherwise break this invariant:
https://github.com/bazelbuild/bazel/blo[]e3e28274cca5b87f48abe33884edb84016dd3/src/main/java/com/google/devtools/build/lib/skyframe/ConfiguredTargetFunction.java#L403
There's no reason (to my knowledge) to need multiple instances of the same <Attribute, Dependency> pair.
More context from Google code review:
(Michael Staib):
> There are many things which pass around a dependentNodeMap or help construct one or modify one. We want an interface which has the right guarantees.
> ListMultimap is not the right interface because it has no guarantee of unique elements, which we want - we don't want the problem that this CL ran into, and there's no reason (that we know of, to be confirmed) that anyone would want multiple identical Dependencies.
> SetMultimap is not the right interface because it has no guarantee of deterministic iteration order or efficient iteration, which we want - dependency order sometimes matters (e.g., Java classpath or C++ link order).
> We agreed that the best way to get what we want is to define our own interface with its own simultaneous uniqueness and iterability guarantees. Unspoken in the discussion was why we wouldn't just use LinkedHashMultimap as the thing we pass around. IMO the reason for that is that we don't care that it be a LinkedHashMultimap specifically; if tomorrow Guava comes out with a faster cooler map that has deterministic and efficient iteration and guarantees element uniqueness, we want it.
> In this case we're going to make the "interface" be a (final?) class: OrderedSetMultimap, an extension of ForwardingSetMultimap which delegates to LinkedHashMultimap, an implementation which does support both of those guarantees.
> I had mentioned in the conversation that none of the Multimap implementations make guarantees about key iteration order, but this is not true - LinkedHashMultimap preserves key insertion order. We should perhaps declare this as part of the OrderedSetMultimap contract as well.
--
MOS_MIGRATED_REVID=130037643
|
| |
|
|
|
|
|
|
|
| |
With this change, dynamic configs are at full feature parity for
split transitions (minus some small differences in composed
transitions from BuildConfigurationCollection.configurationHook).
--
MOS_MIGRATED_REVID=129802414
|
| |
|
|
|
|
|
| |
This fixed some fallout from commit 7894c18dbaf237a1c02d76beabe6ca54faf5039a. I also audited all the sites that change introduced ImmutableMap.Builder at.
--
MOS_MIGRATED_REVID=122738945
|
| |
|
|
|
|
|
| |
This will be used to replace RedirectChaser so that we don't need to load packages during configuration creation anymore.
--
MOS_MIGRATED_REVID=121935989
|
| |
|
|
|
|
|
| |
Except in action execution logic (ActionExecutionFunction, SkyframeActionExecutor, etc.), switch Action interface references to either ActionAnalysisMetadata if possible or ActionExecutionMetadata.
--
MOS_MIGRATED_REVID=120723431
|
| |
|
|
|
|
|
|
|
| |
This should never be triggered in production, where we always run a loading
phase first and only analyze targets that load successfully. I.e., this is
just plumbing which will be hooked up in a subsequent change.
--
MOS_MIGRATED_REVID=113258593
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Dependencies are the data structure which needs to propagate the configuration for each
aspect as created by trimConfigurations down to the point where it's actually used. We
need this to store different configurations for different aspects in a world where aspects
have their own configurations, which may have more fragments than the target they're
attached to.
That world is on its way.
Also in this CL:
* Refactor Dependency to be an abstract parent class with separate implementations for
Attribute.Transitions and BuildConfigurations, as well as null configurations, to avoid
having to check nullness in various places. Users of the API will not see this, but get
factory methods instead of constructors. As a consequence of this, refactor Dependency
to be its own top-level class instead of a nested class in DependencyResolver.
--
MOS_MIGRATED_REVID=113109615
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- update some comments
- add some comments to make it easier to follow
- delete some dead code, in particular the SkyframeDependencyResolver can
never be null; remove an non-applicable @Nullable annotation
I'm trying to figure out how the error handling code works, in order to add
support for interleaved loading+analysis, which requires handling loading
errors in this code path.
--
MOS_MIGRATED_REVID=112456674
|
| |
|
|
|
|
|
| |
Reduces garbage.
--
MOS_MIGRATED_REVID=109914243
|
| |
|
|
|
| |
--
MOS_MIGRATED_REVID=106848269
|
| |
|
|
|
|
|
|
|
|
|
| |
The headers were modified with
`find . -type f -exec 'sed' '-Ei' 's|Copyright 201([45]) Google|Copyright 201\1 The Bazel Authors|' '{}' ';'`
And manual edit for not Google owned copyright. Because of the nature of ijar, I did not modified the header of file owned by Alan Donovan.
The list of authors were extracted from the git log. It is missing older Google contributors that can be added on-demand.
--
MOS_MIGRATED_REVID=103938715
|
| |
|
|
|
|
|
|
|
|
| |
- Label parsing can be simplified
- lib.syntax is only contains the code for Skylark and is reasonably independent from the problem domain of building things
This change is mostly only changes to imports declarations. The rest is reversing the dependency between :cmdline and :syntax and moving a tiny amount of code between Printer and FilesetEntry and the addition of SkylarkPrintableValue that I couldn't be bothered to separate out into its own change.
--
MOS_MIGRATED_REVID=103527877
|
| |
|
|
|
| |
--
MOS_MIGRATED_REVID=103374106
|
| |
|
|
|
|
|
| |
BaseFunction.
--
MOS_MIGRATED_REVID=102988766
|
| |
|
|
|
| |
--
MOS_MIGRATED_REVID=102134151
|
| |
|
|
|
| |
--
MOS_MIGRATED_REVID=102126786
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a big change, so let me walk you through the key pieces:
1) This cl provides an alternative mechanism for creating configurations and doing configuration transitions that's "dynamic" in that the configurations can be created on the fly and the transitions are arbitrary mappings from BuildOptions --> BuildOptions that can also be created on the fly. It also integrates this with ConfiguredTargetFunction, so the configured target graph automatically uses this framework.
2) It does *not* replace old-style (which we'll call "static") configurations. For a number of important reasons: It's not yet at feature parity (particularly: no LIPO). It's not remotely tested across real projects enough to have confidence that it's battle-ready. It doesn't yet handle certain "special" functions like BuildConfiguration.prepareToBuild() and BuildConfiguration.getRoots(). It still relies on the old static transition logic to determine what transitions to apply (eventually we'll distribute that logic out, but that's too much for a single cl). We need the option to toggle it on and off until we have enough confidence in it. So with this cl, builds can be done in either mode.
3) The new flag --experimental_dynamic_configs toggles use of dynamic configurations.
4) Dynamic configurations are created with the Skyframe function BuildConfigurationFunction (this was already created in an earlier change). This consumes a BuildOptions and a set of configuration fragments to produce a BuildConfiguration.
5) Dynamic transitions are instances of the new class PatchTransition, which simply maps an input BuildOptions to an output BuildOptions.
6) Since static and dynamic configurations have to co-exist (for now), this cl tries hard to keep today's transition logic defined in a single place (vs. forking a dedicated copy for each configuration style). This is done via the new interface BuildConfiguration.TransitionApplier. BuildConfiguration.evaluateTransition is modified to feed its transition logic into TransitionApplier's common API. Both dynamic and static configurations have their own implementations that "do the right thing" with the results.
7) The transition applier for dynamic configurations basically stores the Transition, then allows DependencyResolver (which calls BuildConfiguration.evaluateTransition) to return Dependency instances containing that Transition (vs. a BuildConfiguration, which they traditionally contain).
7.5) An earlier variation of the dynamic transition applier retained BuildOptions (e.g. when it got a Transition it immediately applied it to get its output BuildOptions, then stored that). This had the advantage of making composing of transitions easier, especially within BuildConfiguration.evaluateTransition (which can theoretically apply multiple transitions to the input configuration). But it turns out that applying transitions has a cost, and it's simply more performant to pass them through until they're really needed.
8) In dynamic configuration mode, after ConfiguredTargetFunction gets its deps (e.g. an <Attribute, Dependency> multimap), it "trims" the configurations for its dependencies by a) only including config fragments required by the deps' subtrees and b) applying the transitions that came from 7). This all happens in the new method ConfiguredTargetFunction.trimConfigurations.
9) trimConfigurations is heavily performance-optimized based on a lot of experience running this through a large project within Google. As it turns out, the cost of host transitions can be atrocious (because there are a lot of them). Also, BuildOptions.clone() is expensive. And just creating BuildConfiguration SkyKeys also has a cost (largely because of BuildOptions cloning), so that shouldn't be done except when really necessary. My experience with this convinced me it's worth making this method complicated for the sake of making it fast. Since it basically visits every edge in the configured target graph (at least), it really needs to be slick.
10) Since host transitions in particular are problematic w.r.t. speed, I compute the host *once* in ConfigurationCollectionFunction.getHostConfiguration() and expose that reference to ConfiguredTargetFunction and other Skyframe functions. This limits recomputation to just when the fragments are trimmed.
11) Since options cloning is expensive, I'm doing something scary: exposing a BuildConfiguration.getOptions() method that returns a direct reference. Since BuildOptions is mutable, this is dangerous in the wrong hands. I can experiment with going back to cloning (with the caching of host transitions it may not matter as much), but we may ultimately have to put up with this risk for the sake of performant analysis time. What would be *really* awesome would be to make BuildOptions immutable. But that's not going to happen in this cl.
So in short, the key abstractions in this cl are:
- PatchTransition
- BuildConfiguration.TransitionApplier
- ConfiguredTargetFunction.trimConfigurations
The current implementation imposes no analysis time penalty
--
MOS_MIGRATED_REVID=101474620
|
|
|
--
MOE_MIGRATED_REVID=85702957
|
Dmitry Lomov
Greg Estren
Janak Ramakrishnan
Lukacs Berki
Rumou Duan
Ulf Adams
Michael Staib
Mark Schaller
Damien Martin-Guillerez
Florian Weikert
Marian Lobur
Han-Wen Nienhuys