| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
| |
Skyframe.
This avoids some unnecessary iteration over already-emitted events that can show up in profiles, and allows us to store execution-phase values a bit more compactly, since we don't need to carry around wrapper objects and nested sets everywhere.
This crucially depends on the fact that we can't build a target in the execution phase without first having analyzed it in a separate Skyframe call. Skyframe normally propagates all events/posts up the graph because it must be able to emit them if a user requests a node that only transitively depends on the node that emitted an event. However, because we do analysis in a separate Skyframe call, any warnings/posts associated with the analysis nodes will be emitted then, and we don't need to propagate them into execution.
PiperOrigin-RevId: 208767078
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
//src/test/shell/integration:execution_phase_tests
now runs on Windows.
See https://github.com/bazelbuild/bazel/issues/4292
Change-Id: Ia46f26d7fa428cc17cd6988859d427165174fe29
Closes #5688.
Change-Id: I5d001825431e8a0ee7d2ce6be911544b72c3bdd2
PiperOrigin-RevId: 206560081
|
| |
|
|
|
|
|
|
| |
Bazel now has its own subclass of StartupOptions to specify bazel-only options. This is needed for https://github.com/bazelbuild/bazel/issues/4502.
RELNOTES(INC): No longer accepts --blazerc or --[no]master_blazerc, accepts bazelrc name only.
PiperOrigin-RevId: 193718297
|
| |
|
|
|
|
|
|
|
|
|
| |
Removes some duplicate computation by memoizing the results. Consolidates caching into a single optionDefinition object, instead of having multiple caches that go from the option name to different parts of what defines an option.
Fly-by cleanup of OptionDescription's contents, all contents that are statically defined as part of an option are in OptionDefintion, while expansion data, which depends on the existence of other options, is more clearly stored separately.
Will move the converter-to-option type matching sanity checks to a compile time check in a later change.
RELNOTES: None.
PiperOrigin-RevId: 166912716
|
| |
|
|
|
|
|
|
|
| |
This gives us better reliability for detecting file changes; especially in
cases where tools intentionally do not update mtime.
Fixes #1525.
PiperOrigin-RevId: 155490849
|
| |
|
|
|
|
|
|
| |
This logger makes it easier to parse log statements and is now enabled for Bazel's java.log.
RELNOTES[INC]: Bazel now prints logs in single lines to java.log
PiperOrigin-RevId: 152954337
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change adds the new magic value "auto" to --jobs and makes this the
default. When --jobs=auto, we determine the number of available CPU
threads and set a reasonable value for --jobs based on this number. I'm
explicitly not defining what "reasonable" means because we may want to
change the heuristics later on.
The goal here is to reduce the load on the system when running Bazel
while not adversely affecting build times significantly. Previous
versions of Bazel defaulted --jobs to 200, which could easily overload
the local machine with a lot of processes. This value was derived from
Blaze's default, which makes sense because most jobs are network-bound
due to distributed execution; however, in the Bazel case, this never
made sense and is actually harmful.
This change was initiated by problems observed on Macs where Bazel would
bring machines to their knees due to system resource overload. It's
likely that the overload is caused by too much RAM usage rather than
CPU, but both of these should go down with a more limited jobs value.
Should help alleviate issue #1160.
RELNOTES: The --jobs flag now defaults to "auto", which causes Bazel to
use a reasonable degree of parallelism based on the local machine's
capacity.
--
PiperOrigin-RevId: 150466088
MOS_MIGRATED_REVID=150466088
|
|
|
This change modifies DigestUtils to add a cache of (path, inode, mtime,
size) to the digest of the file for those digests that are computed by
reading the file contents.
The cache itself is optional because relying on file metadata to cache
the file digests could lead to correctness issues. Enabling the cache
is exposed via a new (undocumented) --cache_computed_file_digests flag
that we can use post-release to tune the built-in values if they prove
to be incorrect or problematic.
For Bazel, enable this cache unconditionally because the rest of
Bazel already relies on mtimes and other file metadata to determine
changes to files.
The rationale for this change is performance: once we have lost the
in-memory file metadata (e.g. because of a flag flip), Bazel has to
redigest all of the output files to recompute action cache keys. For
a pathological case of rebuilding a large app with 5GB of outputs and
then flipping the --[no]check_visibility flag on the command line, we
get the following numbers before this change:
____Elapsed time: 11.170s, Critical Path: 8.34s
____Elapsed time: 11.027s, Critical Path: 8.20s
____Elapsed time: 11.084s, Critical Path: 7.46s
____Elapsed time: 11.051s, Critical Path: 6.61s
____Elapsed time: 11.211s, Critical Path: 7.81s
____Elapsed time: 10.884s, Critical Path: 8.20s
____Elapsed time: 11.385s, Critical Path: 8.12s
____Elapsed time: 11.723s, Critical Path: 8.18s
____Elapsed time: 11.327s, Critical Path: 7.73s
____Elapsed time: 11.028s, Critical Path: 7.89s
And after this change:
____Elapsed time: 4.294s, Critical Path: 0.27s
____Elapsed time: 4.376s, Critical Path: 0.83s
____Elapsed time: 8.083s, Critical Path: 0.52s
____Elapsed time: 4.302s, Critical Path: 0.64s
____Elapsed time: 4.282s, Critical Path: 0.37s
____Elapsed time: 4.219s, Critical Path: 0.61s
____Elapsed time: 4.214s, Critical Path: 0.97s
____Elapsed time: 4.185s, Critical Path: 0.71s
____Elapsed time: 7.962s, Critical Path: 4.30s
____Elapsed time: 4.149s, Critical Path: 1.03s
--
PiperOrigin-RevId: 150351444
MOS_MIGRATED_REVID=150351444
|
janakr
Laszlo Csomor
ccalvarin
ulfjack
schmitt
Julio Merino