| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
| |
--
MOS_MIGRATED_REVID=132703263
|
|
|
|
|
|
|
|
|
| |
Instead of using a compile-time PRODUCT_NAME constant and complex Build
rules to set the correct product name for Blaze and Bazel, use the new
main.cc files to inject the appropriate value.
--
MOS_MIGRATED_REVID=132675327
|
|
|
|
|
|
|
|
|
| |
- Don't call setrlimit() (it was needed to make 32-bit JVMs work with >3GB heaps)
- Remove a non-functional way to tweak the Linux scheduler
- Cosmetic fixes
--
MOS_MIGRATED_REVID=132653426
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rename BlazeStartupOptions to StartupOptions and turn the latter into a
class that can be subclassed to implement site-specific options
behavior. This lends itself to easier customization for the
site-specific versions, especially if there is more than one, and gets
rid of the strange build-time parameterization of the old
blaze_startup_options*.cc files.
Note that this change introduces various TODOs. This is intentional.
This change is quite complex as it is and I want to focus it on
reshuffling the class structure without actually touching the
internals. The latter can be done in subsequent, more targetted
changes that are easier to review and understand.
--
MOS_MIGRATED_REVID=132555032
|
|
|
|
|
|
|
| |
It is not really actionable and doesn't warn the user against real breakages, so there isn't much point.
--
MOS_MIGRATED_REVID=132541684
|
|
|
|
|
|
|
| |
KillServerProcess() so that we don't call malloc() in signal handlers.
--
MOS_MIGRATED_REVID=132232499
|
|
|
|
|
|
|
|
|
|
| |
History in
https://github.com/emacs-mirror/emacs/blo[]f125aa3de06fa0180a83ec7b5a26970309eeeb6/etc/NEWS#L1769-L1773
RELNOTES: Emacs' [C-x `], a.k.a. next-error, works again in emacsen >= 25.1
--
MOS_MIGRATED_REVID=131851164
|
|
|
|
|
|
|
| |
case the request fails.
--
MOS_MIGRATED_REVID=131804959
|
|
|
|
|
|
|
|
|
|
| |
This change introduces a new workspace_layout module that collects all
the static methods previously contained in the BlazeStartupOptions
class. These methods are not part of the options so it doesn't make
sense for them to be there.
--
MOS_MIGRATED_REVID=131576959
|
|
|
|
|
|
|
|
| |
See GitHub issue #1684:
https://github.com/bazelbuild/bazel/issues/1684#issuecomment-242401560
--
MOS_MIGRATED_REVID=131368104
|
|
|
|
| |
MOS_MIGRATED_REVID=130747105
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Increase the ping timeout on connect from five to ten seconds. This gives
servers which may be suffering from gc pressure or other ailments extra time to
respond.
On the other end, wait for orphaned servers to really die before proceeding.
This prevents race conditions around the delivery of SIGKILL and the starting
of the new server.
This may make us fail slower when the server is having hard times, however it
should give us better determinism, and these conditions should be rare.
--
MOS_MIGRATED_REVID=130118918
|
|
|
|
|
|
|
|
|
| |
the logical rollback of commit 67ad82a319ff8959e69e774e7c15d3af904ec23d.
RELNOTES[INC]: Bazel supports Unix domain sockets for communication between its client and server again, temporarily, while we diagnose a memory leak.
--
MOS_MIGRATED_REVID=130027009
|
|
|
|
|
|
|
|
|
|
| |
It is unused since commit f107debac45ddf5859b1eb963379769b5815b18f: ("
Remove the AF_UNIX client/server communication").
--
Change-Id: Ia4051eb518ab7e97fb0523b0b3cdb4c0f19e704c
Reviewed-on: https://bazel-review.googlesource.com/#/c/4290
MOS_MIGRATED_REVID=129971957
|
|
|
|
|
|
|
|
|
| |
It has been superseded by gRPC.
RELNOTES[INC]: Blaze doesn't support Unix domain sockets for communication between its client and server anymore. Therefore, the --command_port command line argument doesn't accept -1 as a valid value anymore.
--
MOS_MIGRATED_REVID=129424092
|
|
|
|
|
|
|
| |
instead of AF_UNIX.
--
MOS_MIGRATED_REVID=128962306
|
|
|
|
|
|
|
|
|
|
| |
GetNullaryOption() is a function whose return type is bool, which can
only return two possible values, true or false, and thus can not return NULL.
--
Change-Id: If9fc622d7132b15268bdcc76aed8d04fe5b92bc7
Reviewed-on: https://bazel-review.googlesource.com/#/c/4140/2
MOS_MIGRATED_REVID=128448779
|
|
|
|
|
|
|
|
|
|
|
|
| |
Address the following warnings from the compiler:
* "control reaches end of non-void function [-Wreturn-type]"
* "dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]"
* "ignoring return value of 'ssize_t write(int, const void*, size_t)', declared with attribute warn_unused_result [-Wunused-result]"
* "ignoring return value of 'int ftruncate(int, __off_t)', declared with attribute warn_unused_result [-Wunused-result]"
* "ignoring return value of 'int dup(int)', declared with attribute warn_unused_result [-Wunused-result]"
--
MOS_MIGRATED_REVID=128375065
|
|
|
|
| |
MOS_MIGRATED_REVID=128348972
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=128195657
|
|
|
|
|
|
|
|
|
|
|
| |
Darwin.
This is equivalent to what Xcode does with the directories that it generates as part its builds.
fix for https://github.com/bazelbuild/bazel/issues/1514
--
MOS_MIGRATED_REVID=127927131
|
|
|
|
|
|
|
| |
This is to maintain some semblance of sanity on pre-Windows 8 systems where nested jobs are not supported. In that case, it's possible that the server is already in a job.
--
MOS_MIGRATED_REVID=127810008
|
|
|
|
|
|
|
| |
Fix for: https://github.com/bazelbuild/bazel/issues/1511
--
MOS_MIGRATED_REVID=127722500
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=127700522
|
|
|
|
|
|
|
|
|
| |
path length (as opposed to simple PATH_MAX).
Turns out, NTFS does support path lengths longer than PATH_MAX here, let's be resilient against that.
--
MOS_MIGRATED_REVID=127699843
|
|
|
|
|
|
|
| |
on busy machines.
--
MOS_MIGRATED_REVID=127538222
|
|
|
|
|
|
|
|
|
| |
Turns out, one second is not enough and on very busy machines, the server can be perfectly healthy and still take more than a second to answer.
When the port is not open, it will return quickly anyway.
--
MOS_MIGRATED_REVID=127537803
|
|
|
|
|
|
|
| |
--
Change-Id: Ib480661ebbc522007edd77b374d6720d216b4508
Reviewed-on: https://bazel-review.googlesource.com/#/c/4050
MOS_MIGRATED_REVID=127534581
|
|
|
|
|
|
|
|
|
| |
Well, this is embarrassing.
Fixes #1526.
--
MOS_MIGRATED_REVID=127532256
|
|
|
|
|
|
|
|
|
| |
Also removed previous workaround in cc_configure.bzl
--
Change-Id: I6dcd039fc5e18af8f2d21969641d6bbd05c8badc
Reviewed-on: https://bazel-review.googlesource.com/#/c/4034
MOS_MIGRATED_REVID=127518922
|
|
|
|
|
|
|
| |
--
Change-Id: I66e8bc8dea7a5cef8eeccc0afebdc06f1b2a8a58
Reviewed-on: https://bazel-review.googlesource.com/#/c/4033/
MOS_MIGRATED_REVID=127418054
|
|
|
|
|
|
|
|
| |
Closes #1419.
--
Reviewed-on: https://github.com/bazelbuild/bazel/pull/1419
MOS_MIGRATED_REVID=127326203
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=127319649
|
|
|
|
|
|
|
|
|
|
|
| |
passes between the Ping() and Run() calls and make Ping() and Cancel() calls restart the server timeout interval.
This "fixes" a race condition where the client would call Ping(), the server would time out and then the Run() call would fail. Of course, this is not an principled fix because in theory, the timeout can still happen between the two calls, but now there are only simple file system operations and a tiny bit of CPU use between the two so it should be vanishingly unlikely. We use ->Ping() to verify server liveness after we start it up, so in theory, the timeout could strike between those two calls, too...
TESTED=By running "bazel --max_timeout_secs=2 info install_base" 100 times in a test and running the test 200 times. This procedure triggered the bug pretty reliably.
--
MOS_MIGRATED_REVID=126902519
|
|
|
|
|
|
|
|
| |
- Use the abrupt exit protocol to return the correct exit code when the server dies unexpectedly in gRPC mode
- Report the command waiting time correctly even if the waiting is done within the server
--
MOS_MIGRATED_REVID=126780186
|
|
|
|
|
|
|
|
|
| |
The cleanup is much less orderly than on Unix: we simply rely on Windows to terminate all child processes by putting the Bazel binary in a job.
Fixes #1134.
--
MOS_MIGRATED_REVID=126686643
|
|
|
|
|
|
|
| |
sane Java API for now)
--
MOS_MIGRATED_REVID=126306559
|
|
|
|
|
|
|
|
| |
These don't do anything for a 64-bit JVM.
Also remove some very old GC tuning flags for --batch.
--
MOS_MIGRATED_REVID=126303269
|
|
|
|
|
|
|
| |
Fixes #1445.
--
MOS_MIGRATED_REVID=125773835
|
|
|
|
|
|
|
| |
Bazel is using the right value.
--
MOS_MIGRATED_REVID=125764994
|
|
|
|
|
|
|
| |
of the server on Windows, too.
--
MOS_MIGRATED_REVID=125758769
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=125663574
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=125589653
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-XX:TieredStopAtLevel=1 instead of -client, as the latter is ignored on 64-bit JVMs since at least JDK 6.
The new flags have been shown to cut down CPU time by 50% due to reduced time spent in JIT and improving overall run time for short running actions, some times also cutting them in half.
Here's a benchmark of Bazel building itself, giving a nice 2-4x speedup:
./output/bazel clean && ./output/bazel build //src:bazel
Bazel before this change:
INFO: Elapsed time: 197.783s, Critical Path: 194.10s
INFO: Elapsed time: 198.928s, Critical Path: 195.65s
INFO: Elapsed time: 194.913s, Critical Path: 191.56s
Bazel before this change with --strategy=Javac=worker:
INFO: Elapsed time: 130.436s, Critical Path: 124.27s
INFO: Elapsed time: 116.114s, Critical Path: 112.30s
INFO: Elapsed time: 116.852s, Critical Path: 84.45s
Bazel with this change:
INFO: Elapsed time: 121.625s, Critical Path: 119.08s
INFO: Elapsed time: 119.401s, Critical Path: 115.80s
INFO: Elapsed time: 121.198s, Critical Path: 119.03s
Bazel with this change and --strategy=Javac=worker:
INFO: Elapsed time: 54.456s, Critical Path: 51.28s
INFO: Elapsed time: 53.272s, Critical Path: 51.09s
INFO: Elapsed time: 52.966s, Critical Path: 49.86s
Bazel with this change and --strategy=Javac=worker and stripping -XX:TieredStopAtLevel=1 from JVM flags when using workers:
INFO: Elapsed time: 61.599s, Critical Path: 58.93s
INFO: Elapsed time: 48.695s, Critical Path: 45.02s
INFO: Elapsed time: 46.874s, Critical Path: 43.91s
INFO: Elapsed time: 46.174s, Critical Path: 43.32s
(The latter is a possible optimization for workers and it's also nice to know that the limited tiered compilation does not hurt their performance.)
--
MOS_MIGRATED_REVID=125448089
|
|
|
|
|
|
|
|
|
| |
handler in the client.
This makes Ctrl-C work on Windows somewhat: in particular, in non-batch mode and while no actions are running.
--
MOS_MIGRATED_REVID=125318172
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=125171210
|
|
|
|
|
|
|
| |
Fixes #1336.
--
MOS_MIGRATED_REVID=124231262
|
|
|
|
|
|
|
|
|
|
|
| |
(finally) delete Constants.java.
For bazel the file Constants.java is the only source of
src/main/java/com/google/devtools/build/lib:common and since it was exporting
guava then many dependencies needed to be fixed.
--
MOS_MIGRATED_REVID=123648270
|
|
|
|
|
|
|
|
|
|
|
| |
handle SIGINT.
std::mutex and friends are not safe from signal handlers . I originally dismissed this approach because I thought it would be complicated, but it turned out to be much, much simpler than what we had before.
The alternative would be signalfd(), which is Linux-only.
--
MOS_MIGRATED_REVID=123578795
|
|
|
|
|
|
|
|
|
| |
pessimistically OOMing when GC thrashing. The first seems to make us hang on OOM, which is kind of the opposite of what we want.
These flags are now even more terribly named than they used to be, but a rename can wait until we actually know what we want.
--
MOS_MIGRATED_REVID=123036704
|