| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
and separation of concerns.
--
MOS_MIGRATED_REVID=122067150
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=121996611
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some had incorrect words, or were missing a word and the end period.
Make it match with the descriptions in CommonCommandOptions.java.
Add a short documentation comment to |restart_reason| field.
--
Change-Id: Iac802eb3ed4f72dfd402e85d2098a5616b40a9de
Reviewed-on: https://bazel-review.googlesource.com/3530
MOS_MIGRATED_REVID=121478703
|
|
|
|
|
|
|
|
|
| |
doesn't exist.
It may be an old version that doesn't know how to write them yet.
--
MOS_MIGRATED_REVID=121462577
|
|
|
|
|
|
|
|
|
|
|
| |
actually a server process.
This should be implemented for other OSes, too, but OS X seems to lack a procfs and it's not clear how to discover anything about a process based on its PID and of course, Windows is a wholly different cup of tea.
More work for #930.
--
MOS_MIGRATED_REVID=121262673
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Made the control flow much simpler and more understandable
- Added some documentation about the interplay of the client and the server
- Abstracted out POSIX mechanisms from blaze.cc so that they can be implemented properly on Windows
- Added assertions that the methods on BlazeServer are called when they should be
Polish for #930.
--
MOS_MIGRATED_REVID=121256601
|
|
|
|
|
|
|
|
|
| |
This is so that only one server instance is started up if two clients are started in a workspace that doesn't have a running server yet.
More work towards #930. This may break Windows in case flock() doesn't work there as expected. In anticipation of this, locking is moved to blaze_util_platform.h / blaze_util.cc .
--
MOS_MIGRATED_REVID=121013078
|
|
|
|
|
|
|
|
|
| |
This is still fallout from a bad merge I did yesterday.
More progress towards #930.
--
MOS_MIGRATED_REVID=121006319
|
|
|
|
|
|
|
|
|
| |
Fixes #1205 .
--
Change-Id: Ifd35cf141737f755b499a786cf9663153cd2cf53
Reviewed-on: https://bazel-review.googlesource.com/#/c/3513/
MOS_MIGRATED_REVID=120998788
|
|
|
|
|
|
|
| |
way that actually works.
--
MOS_MIGRATED_REVID=120997894
|
|
|
|
|
|
|
|
|
| |
This change makes it possible to build Bazel with itself in server mode.
Progress towards #930 . Does not completely fix it because there are still a bunch of issues that need to be taken care of, but it's usable.
--
MOS_MIGRATED_REVID=120994369
|
|
|
|
|
|
|
|
|
|
|
|
| |
The correct spelling of it, is, of course, "common".
While at this, this also fix a mistaken usage of "from" instead of
"form" in ConvertPath() documentation.
--
Change-Id: If93984b57da0c98b6dfe4ca70fd4158bd9e1a861
Reviewed-on: https://bazel-review.googlesource.com/#/c/3500
MOS_MIGRATED_REVID=120921796
|
|
|
|
|
|
|
|
|
| |
AF_UNIX doesn't work on Windows, so it doesn't make much sense to try.
Progress towards #930.
--
MOS_MIGRATED_REVID=120912873
|
|
|
|
|
|
|
|
|
| |
This is necessary because msys2 signals don't work on native Win32 processes, for example, java.exe .
Forcefully terminating the process still doesn't work because it uses signals. It's a-coming.
--
MOS_MIGRATED_REVID=120903711
|
|
|
|
|
|
|
| |
This is necessary because a SIGINT can strike at any time, including when the main thread holds the mutex.
--
MOS_MIGRATED_REVID=120816015
|