| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
This is to allow OptionsProviders to access the new skylark options which aren't held in a fragment class like native options and thus can't be accessed with the traditional <code>get</code> method. Currently this function isn't called anywhere and would just return an empty map. But in the future it will return a map of skylark flag names to values.
PiperOrigin-RevId: 208552510
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Using a thread-safe container to store handlers.
- Using a ThreadLocal NumberFormat to produce readable action counts.
NumberFormat (or rather the default implementation DecimalFormat) use
internal state and locking.
- Adding a lock-free fast path for START and FINISH events in
ExperimentalEventHandler.
RELNOTES: None.
PiperOrigin-RevId: 208479896
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a new PrepareAnalysisPhaseFunction, which started out as a copy of
some existing code from SkyframeExecutor, BuildView, AnalysisPhaseRunner,
AnalysisUtils, and ConfigurationResolver, which was then modified to work
inside Skyframe.
Most of our tests already work with the new code, except for some of the tests
related to configuration trimming in combination with dependency cycles. The
reason for this is that we can only recover from dependency cycles at the end
of a Skyframe invocation, but never inside a Skyframe invocation. The new code
therefore cannot return partial results like the old code.
This seems to make null builds a bit faster. In my testing, I saw null build
times for a single test target go from ~50ms to ~40ms. This is probably due to
slightly better caching - it seems that computing the configuration transitions
and top-level targets is non-negligible, even if there's only a single
top-level configuration for a single top-level target.
This might be an even bigger win if there are a lot of top-level targets and
configurations.
PiperOrigin-RevId: 207083192
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 206741115
|
|
|
|
|
|
| |
full mapping unless requested. This gets rid of any performance issue for the vast majority of builds. Second, if requested, use a custom data structure so that we don't have to create a full HashSet for artifacts whose only owning labels are their own owner labels.
PiperOrigin-RevId: 206610370
|
|
|
|
|
|
| |
used at the start of execution.
PiperOrigin-RevId: 206230049
|
|
|
|
|
|
|
|
| |
Instead of using the default thread pool size of 200, use the number set for
the loading phase. This is in preparation for interleaving the loading and
target pattern eval phases.
PiperOrigin-RevId: 206172915
|
|
|
|
|
|
|
|
|
|
|
| |
Instead, refactor the code to use TargetPatternPhaseValue exclusively. This
removes the need to convert from TargetPatternPhaseValue to LoadingResult, and
prepares for interleaving.
It also reduces the number of Skyframe calls which may speed up null builds a
bit, as a followup for https://github.com/bazelbuild/bazel/commit/1067310e18cb9ac203110726de0be53bdc403cea.
PiperOrigin-RevId: 205989338
|
|
|
|
|
|
|
|
|
|
|
| |
Also simplify LoadingPhaseCompleteEvent, and SkyframeExecutor, and remove
LoadingCallback, which is unnecessary now that we only have a single
implementation (previously LoadingPhaseRunner).
This also removes some of the excessive Skyframe calls introduced by
https://github.com/bazelbuild/bazel/commit/1067310e18cb9ac203110726de0be53bdc403cea, and prepares for interleaving target pattern eval and loading.
PiperOrigin-RevId: 205813197
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 205635805
|
|
|
|
|
| |
RELNOTES: Add aquery command to get analysis time information about the action graph.
PiperOrigin-RevId: 205064145
|
|
|
|
|
|
|
|
| |
available.
The owning labels are the labels of the top-level configured targets that requested this artifact to be built (there may be many such targets). In cases where the artifact is added not through a configured target (build-info artifacts and coverage artifacts), the label of the artifact's owner is used.
PiperOrigin-RevId: 204432951
|
|
|
|
|
|
|
| |
Also introduce NamedThreadSafeOutputFormatterCallback for common code.
RELNOTES: None
PiperOrigin-RevId: 203932877
|
|
|
|
|
|
|
| |
PiperOrigin-RevId: 203300374
Change-Id: Iaa47f870ab2e0cad40a202aad2c7f9430f73c856
PiperOrigin-RevId: 203407392
|
|
|
|
|
|
|
| |
This is in preparation for interleaving them.
RELNOTES: None
PiperOrigin-RevId: 201652267
|
|
|
|
|
|
|
| |
To start we add just a single metric, the number of actions constructed in the current build.
RELNOTES: None
PiperOrigin-RevId: 201248490
|
|
|
|
|
|
|
| |
The memory savings from this flag are not worth the complexity, and it interferes with action restarting.
RELNOTES: Remove support for --discard_actions_after_execution.
PiperOrigin-RevId: 201077905
|
|
|
|
|
|
| |
Moves more Action-oriented from skyframe package, which has become very unwieldy, to action package. This is needed to avoid circular dependencies caused when build-base is needed for skyframe.
PiperOrigin-RevId: 200996982
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The intent is that the main thread has ~zero gaps in the profile (though there
may still be small gaps due to the time between one try block and an
immediately subsequent try block).
We need to be careful not to wrap markPhase calls (or methods that call
markPhase) in try blocks for the profiler - the Profiler requires that all
markPhase calls happen at top level, and throws an exception if not.
This should not have any performance impact - all of these are once per build,
or at most once per module per build, and we don't expect a very large number
of modules (and if we see an increasing number, we need to change the module
API to not have to call every single module, but only those that are actually
interested in certain events, maybe with an EventBus-based setup).
PiperOrigin-RevId: 200712677
|
|
|
|
|
|
| |
This is in preparation for interleaving config creation with loading+analysis.
PiperOrigin-RevId: 200695071
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After this change, Bazel prints a warning when
--use_top_level_targets_for_symlinks is active and the destination of
a symlink would be ambiguous.
This also includes a refactoring of OutputDirectoryLinksUtils to use a
single source of truth for all symlink operations. This results in a
few small visible behavior changes:
* Bazel used to delete a convenience symlink with the name of the
workspace from the WORKSPACE file... but it didn't create it.
* Bazel used to check for a convenience symlink named "includes" when
pretty-printing paths... but it didn't create it.
* Bazel used to ignore the existence of the "testlogs" symlink when
pretty-printing paths... despite that it created it.
* Bazel used to prioritize the execroot over the output base when
pretty-printing paths... despite that the former contains the latter.
RELNOTES: None.
PiperOrigin-RevId: 200629863
|
|
|
|
|
|
| |
This reduces our reliance on ProfilerTask.
PiperOrigin-RevId: 200538769
|
|
|
|
|
|
|
| |
This is in preparation for dismantling BuildView and merging the relevant
parts into AnalysisPhaseRunner.
PiperOrigin-RevId: 200391088
|
|
|
|
| |
PiperOrigin-RevId: 200363345
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When this flag is turned on, and the user's working directory is beneath the
workspace (but is not the workspace itself), the workspace's absolute path is
printed as a prefix to the convenience symlink.
With this flag off, the displayed convenience symlink path is always relative
to the user's workspace, even if that isn't the current working directory.
(This is the current behavior.)
The new (flag-on) behavior will become default soon, and then this flag will
be removed.
RELNOTES: None.
PiperOrigin-RevId: 200278355
|
|
|
|
| |
PiperOrigin-RevId: 200210007
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- the TargetPatternPreloader is still used for query in all its forms
- the remaining TargetPatternEvaluator part is no longer used except in tests
- also make both implementations stateless and pass the offset to the methods
instead; note that they both modify the underlying skyframe graph, so there
are side effects to the calls even if there's no direct state anymore
The intent is to migrate the relevant tests to LoadingPhaseRunnerTest (which
could also now be renamed since it's not doing a loading phase), and then
delete the TargetPatternEvaluator interface.
This depends on the previous commit that removed the last direct use of TPE
from an internal command.
PiperOrigin-RevId: 200198067
|
|
|
|
|
|
| |
- migrate all startTask/completeTask pairs to the new API
PiperOrigin-RevId: 200038703
|
|
|
|
|
|
|
| |
This is the first step on the way to a proper action graph query command.
RELNOTES: None
PiperOrigin-RevId: 200026440
|
|
|
|
|
|
|
|
| |
Instead, add some simple APIs to ExecutorBuilder and inline all the previous
subclasses into their corresponding modules. This removes a bunch of
boilerplate.
PiperOrigin-RevId: 200017162
|
|
|
|
| |
PiperOrigin-RevId: 199775400
|
|
|
|
| |
PiperOrigin-RevId: 199732415
|
|
|
|
|
|
| |
needed: we can get the ConfiguredTargetKey directly from the TargetCompletionKey. Since that was the only use of the actual value in EvaluationProgressReceiver#evaluated, remove it, instead just provide a boolean enum that gives whether or not evaluation succeeded.
PiperOrigin-RevId: 199178047
|
|
|
|
|
|
| |
ConfiguredTarget. Since ConfiguredTarget does not implement equals(), reference equality has been used until now, and this is not valid for the case where the ConfiguredTarget has been deserialized.
PiperOrigin-RevId: 199133926
|
|
|
|
|
|
|
| |
This is in preparation for adding options to the class, which can be used
to modify the behavior of build events posted to the BEP.
PiperOrigin-RevId: 196997573
|
|
|
|
|
|
| |
CommonCommandOptions to better facilitate certain kinds of benchmarking.
PiperOrigin-RevId: 196695342
|
|
|
|
|
|
|
|
| |
it off after a release.
Discarding actions hasn't been shown to have a significant positive effect on heap memory usage, after careful research by mschaller@. It's holding back other projects (threading Fileset metadata through) and adding complexity, so it's time to kill it. Out of an abundance of caution, I'll keep actions in memory via a flag flip, then, if it sticks, I'll change the default, and then I'll unwire everything.
PiperOrigin-RevId: 196682768
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 195428899
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 195422399
|
|
|
|
|
|
|
|
|
|
|
|
| |
This effectively subsumes all existing memory estimation, as it no
longer matters too much how much memory is assigned to each action.
WIP: This is a hack, and if it goes in, should almost certainly be
hidden behind a configuration option.
Closes #4938.
PiperOrigin-RevId: 195378568
|
|
|
|
| |
PiperOrigin-RevId: 194099006
|
|
|
|
|
|
|
|
|
|
| |
This RuleTransitionFactory will be applied to all targets after other
transitions, and is intended to be used to manually trim the configuration
based on tagging of that target. This is a stopgap feature until automatic
trimming of configuration can be implemented.
RELNOTES: None.
PiperOrigin-RevId: 193573013
|
|
|
|
|
|
| |
--[no]proto:include_configurations which when used, makes cquery proto output appear exactly like query proto output so tools that are already using this can seamlessly transition.
PiperOrigin-RevId: 192470626
|
|
|
|
|
|
| |
used without the --transitions flag
PiperOrigin-RevId: 191755762
|
|
|
|
|
|
|
|
|
| |
The current output was pretty much completely incorrect. However since the result output was always hidden for the default value of --show_result, users simply didn't see the incorrect output (instead getting no output at all).
This CL fixes both the --show_result problem and makes the output correct.
RELNOTES: Print correct build result for builds with --aspects flag.
PiperOrigin-RevId: 191456352
|
|
|
|
| |
PiperOrigin-RevId: 190777533
|
|
|
|
|
|
|
|
|
| |
These have all had a chance to be categorized with the OptionDocumentationCategory enum, and the help output already uses the enum-grouped format.
The "incompatible changes" category has meaning for --all_incompatible_changes and will be removed separately.
RELNOTES: None.
PiperOrigin-RevId: 190773778
|
|
|
|
|
|
| |
cquery output callback logic
PiperOrigin-RevId: 190667120
|
|
|
|
|
|
| |
most elegant solution, but I don't have a better idea.
PiperOrigin-RevId: 190656869
|
|
|
|
|
|
| |
holds a variety of strategy/context maps.
PiperOrigin-RevId: 190491357
|