aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/runtime/BlazeServerStartupOptions.java
Commit message (Collapse)AuthorAge
* Add a option to disable idle gc.Gravatar Benjamin Peterson2018-08-08
| | | | | | | | | | | | | | | If a Bazel server is idle for 10 seconds, it unconditionally triggers a full-scale Java GC via System.gc(). This behavior doesn't have clear benefits and causes Bazel to steal resources from whatever the user does after invoking Bazel. This CL adds a startup option, --idle_server_tasks, to toggle the idle GC behavior. Also, add some logging for when idle GC is enabled, so it's easier to evaluate its effects. Example of logging: ``` 180718 17:43:04.609:I 247 [com.google.devtools.build.lib.server.IdleServerTasks.lambda$idle$0] [Idle GC] used: 157MB -> 15MB, committed: 421MB -> 422MB ``` Fixes https://github.com/bazelbuild/bazel/issues/5589. Closes #5628. PiperOrigin-RevId: 207869996
* Add a normal startup-option for setting the digest function.Gravatar ccalvarin2018-08-01
| | | | | | | | | We continue to support the jvm property -Dbazel.DigestFunction, for backwards compatibility, but this will go away. The startup-option is marked experimental for now as we iron out issues. (note: leaving this out of release notes until the experimental tag is removed) As part of this refactor, the default constructor calls for FileSystem and derived classes will now use this default. This should remove the need for constructors that accept custom hash functions. RELNOTES: None. PiperOrigin-RevId: 207035217
* Replace instances of Blaze with Bazel.Gravatar Dan Fabulich2018-07-05
| | | | | | | PiperOrigin-RevId: 203300374 Change-Id: Iaa47f870ab2e0cad40a202aad2c7f9430f73c856 PiperOrigin-RevId: 203407392
* Remove fixed point config expansion.Gravatar ccalvarin2018-06-14
| | | | | | | Deprecates the flag, though it continues to exist as a no-op so that users get a warning before errors. RELNOTES: --noexpand_configs_in_place is deprecated. PiperOrigin-RevId: 200572053
* Mark --batch as deprecated in the documentation.Gravatar ccalvarin2018-06-06
| | | | | RELNOTES: None. PiperOrigin-RevId: 199503117
* Port bazelrc flags into their own module.Gravatar ccalvarin2018-05-16
| | | | | | | | | This way the documentation logs them correctly as named "bazel," and describes the correct behavior. Needed for #4502. RELNOTES: None. PiperOrigin-RevId: 196837021
* Add --ignore_all_rc_files startup options.Gravatar ccalvarin2018-05-15
| | | | | | | | | | | | | This overrides --bazelrc and --[no]master_bazelrc regardless of order. Like --bazelrc and --[no]master_bazelrc, it cannot be mentioned in an rc file, this would be a contradiction. This flag is useful for testing, and for having a version-agnostic way to turn off all rc files, such as in the canonical command line reporting. Now that blazerc and bazelrc are separate, this is necessary. If explicit values for --bazelrc or --master_bazelrc are provided which are now ignored, Bazel will warn the user. #4502 Alternatives considered - We could avoid this flag but would need to have some well-documented, reusable list of the startup flags that effectively come to the same effect. This would be necessary in our integration tests and in the CommandLineEvent and other places where rc files need to be completely disabled for correctness. We decided that this startup option was more straightforward and usable for both users and Bazel devs: it shouldn't be used when more fine-grained control is needed, but provides warnings if users are likely to be confused by the outcome. RELNOTES: None. PiperOrigin-RevId: 196750704
* Use the local JDK as the default target javabaseGravatar cushon2018-05-14
| | | | | | and continue to use the embedded JDK as the default host_javabase. PiperOrigin-RevId: 196471714
* Make the client's java startup command line list all startup options.Gravatar ccalvarin2018-03-30
| | | | | | | | | | | We expect that the client passes all startup options to the server, default or explicit. The server's listing of default values should not matter. Yet for a number of these options, the default value in the server was relied upon, because the server command line was not constructed with the client's default value included. Fix visible cases of this, long term this should be tested for, so the invariant is not broken again. This has been the documented expectation for a long time, but a number of violations have crept up over time. Update the comments that lead to this expectation to be more realistic. Add debug statement that shows which options are changed when startup options cause the server to be restarted. The detailed logs will only be seen if --client_debug is set to TRUE. RELNOTES: None. PiperOrigin-RevId: 191066983
* Remove categories from Bazel options.Gravatar ccalvarin2018-03-28
| | | | | | | | | 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
* Update the client's skeleton logging framework to use it for --client_debug.Gravatar ccalvarin2018-03-21
| | | | | | | | | We are still unable to turn this on to write to files, but there are currently 2 logging systems in use in the client: the inactive one, and the print-to-stderr option triggered by --client_debug. Combine these, so we can use the same logging format for both. Also combine it with the VerboseLogging functionality - it was not documented anywhere and seems redundant. RELNOTES: None. PiperOrigin-RevId: 189979051
* Remove internal-only startup option from documentation.Gravatar ajmichael2018-03-07
| | | | | RELNOTES: None PiperOrigin-RevId: 188179200
* Expose --output_user_base to the Bazel server processGravatar Klaus Aehlig2018-02-27
| | | | | | | | | | | ...so that it can use that path to compute other directories in the output user base, in particular the default location for caches. The first cache we will add is the hash-index cache for downloads of external archives, but a spawn cache might be added later in the output user base as well. Change-Id: I24b1c33235c8f76ec008ecb1789163de2b2a45be PiperOrigin-RevId: 187164275
* Flip --expand_configs_in_place to true by default in Bazel.Gravatar ccalvarin2018-02-23
| | | | | | | See https://blog.bazel.build/2018/01/19/config-parsing-order.html for context on this change. RELNOTES: --config flags now expand in place by default. PiperOrigin-RevId: 186831701
* Support explicitly specifying a location for jvm.outGravatar michajlo2018-01-29
| | | | | | | | Allows users to monitor server output without needing to fish the output base. Windows support is copied more or less verbatim from recommendations, I unfortunately don't know how to test this on windows. PiperOrigin-RevId: 183674130
* PiperOrigin-RevId: 183094604Gravatar ajmichael2018-01-24
|
* PiperOrigin-RevId: 179941785Gravatar Googler2017-12-22
|
* PiperOrigin-RevId: 179932935Gravatar ajmichael2017-12-22
|
* Change config expansion application order, gated by startup flag ↵Gravatar ccalvarin2017-11-20
| | | | | | | | | | | | | --expand_configs_in_place. --config options were expanded in a fix-point expansion, where in practice, the flags that --config values expanded to ended up between the normal bazelrc options and the command line's explicit options. Since the options parser has an order-based priority scheme and it accepts multiple mentions of a single-valued option, this conflicts with users' expectations of being able to override these config expansions by using the order in which they are mentioned. This change makes it possible to expand the config values defined in your bazelrc (or blazerc) files to occur in-place: --stuff --config=something --laterstuff will interpret the options that --config=something expands to as if they had been mentioned explicitly between --stuff and --laterstuff. In order to not break users relying on complex flag combinations to configure their builds, this behavior will not yet be turned on by default. Instead, use --expand_configs_in_place as a startup flag to test this feature. --announce_rc may be helpful for debugging any differences between the fixed point and in-place expansions. Once you've debugged your problems, add "startup --expand_configs_in_place" to your blazerc to stick to the new behavior. RELNOTES: Use --expand_configs_in_place as a startup argument to change the order in which --config expansions are interpreted. PiperOrigin-RevId: 176371289
* Increase the connection timeout between the client and the server.Gravatar lberki2017-09-25
| | | | | | | Very large server instances can take >10 seconds for GC, and if they are hit at an inopportune moment, they may get killed needlessly. RELNOTES: None. PiperOrigin-RevId: 169905185
* Add the command option --experimental_oom_more_eagerly_threshold. This will ↵Gravatar janakr2017-08-16
| | | | | | replace the startup option after a deprecation period. PiperOrigin-RevId: 165340514
* Make the @Option annotation depend on the java version of the tagging enums.Gravatar ccalvarin2017-07-18
| | | | | | | The option filters proto dependency can be removed from the OptionsParser. This is in response to option parser users that want to avoid the bazel-internal proto file in their dependencies. RELNOTES: None. PiperOrigin-RevId: 162249778
* Fold OptionUsageRestrictions into OptionDocumentationCategory and ↵Gravatar ccalvarin2017-07-11
| | | | | | | | | | OptionMetadataTags. These are similar, no need to have both fields. Removing the "DOCUMENTED" default, the absence of UNDOCUMENTED will be used instead. Since requiring a documentation category for undocumented options doesn't make sense, list that as one of the OptionDocumentationCategories, but list HIDDEN and INTERNAL as part of OptionMetadata. These options should list UNDOCUMENTED as their category. PiperOrigin-RevId: 161515674
* Add the default category and tag to all options.Gravatar ccalvarin2017-06-28
| | | | | | | | Move the default from the annotation to every mention. This makes the incompleteness explicit. Will add the defaults to test targets in a separate change. Once all dependencies are cleaned up, the Option annotation will no longer allow options without the documentationCategory or effectTag, to prevent new options being added without categories while we migrate to the new option categorization. PiperOrigin-RevId: 160281252
* Add option tagging and categorizing enums.Gravatar ccalvarin2017-06-27
| | | | | | | | | | | | | | Begin work of transferring option categorization to a sustainable, documented setup. DocumentationCategories will replace the existing string category field, and will group flags in generated documentation. Each flag must belong to exactly 1 DocumentationCategory, whichever is most applicable or a new one. OptionEffectTags will document the effects of tags and will be used for filtering flags. These tags, unlike the categories, should be complete. All options that do affect Bazel's output should be tagged as affecting Bazel's output, for example. This is necessary for them to be useful when trying to isolate the cause of an issue or behavior by allowing irrelevant options to be filtered out. Each flag must have at least 1 intended behavior, so should have 1+ OptionEffectTag. If no effect tag applies, find a general tag that would apply and add it to all relevant options. OptionMetadataTags will hold information about the flag itself. Information about the lifecycle of a flag, for example, should belong in an OptionMetadataTag. It is useful for filtering, since it describes how trustworthy we might think the flag would be, but does not actually describe the “intent” or “meaning” of a flag. This can be an empty list, but options can also have multiple OptionMetadataTags All options will be switched from the old "category" field to this new system. A few general OptionsBases are provided as an example. PiperOrigin-RevId: 160180328
* Move command.log writing to a moduleGravatar ulfjack2017-06-26
| | | | | | | This is part of refactoring / simplifying the BlazeCommandDispatcher. RELNOTES: None. PiperOrigin-RevId: 160110866
* Change help message for --batchGravatar Mike Morearty2017-06-06
| | | | | | | | | | The help message previously said that `--batch` is strongly discouraged, but in fact it's only discouraged when using bazel interactively. Since the tradeoffs of `--batch` are fully explained in the online docs, this commit changes the help message to explain what the option does without getting into the tradeoffs. Fixes #3051 Closes #3118. PiperOrigin-RevId: 158112611
* Split out option usage restriction from option category.Gravatar ccalvarin2017-04-18
| | | | | | | | | These are two different concepts. Do not remove category overload compatibility in this CL, to keep this change limited to converting the current uses of category. With some flyby formatting fixes on affected OptionsBases. RELNOTES: None. PiperOrigin-RevId: 153390002
* Remove configurability of abrupt exit code behavior.Gravatar ccalvarin2017-03-29
| | | | | | | | Ability to configure this was added to provide an easy correction in case writing the exit code to a file proved problematic. This feature has been out for 3 months with no reported issues, no reason to keep the extraneous flag. PiperOrigin-RevId: 151496431
* Convert --use_action_cache to a regular optionGravatar Googler2017-03-01
| | | | | | | | RELNOTES: Convert --use_action_cache to a regular option -- PiperOrigin-RevId: 148804881 MOS_MIGRATED_REVID=148804881
* Adds --[no]use_action_cache startup option to disable the action cache.Gravatar Googler2017-02-15
| | | | | | | | | Disabling the action cache is helpful in contexts where incremental builds are not required, or where actions need to be repeatedly executed for debugging. -- PiperOrigin-RevId: 147485055 MOS_MIGRATED_REVID=147485055
* Record correct exit code for uncaught exceptions in async threads.Gravatar Chloe Calvarin2016-12-13
| | | | | | | | | | Async threads are divorced from the server's error-reporting mechanism. In the event of a server shutdown originating in an async-thread, write the exit code to a file that can be read by the client. -- PiperOrigin-RevId: 141920284 MOS_MIGRATED_REVID=141920284
* Add two startup options:Gravatar Lukacs Berki2016-11-08
| | | | | | | | - --client_debug that turns out debug logging from the client - --connect_timeout_secs that controls the timeout of the initial Ping() RPC from the client to the server -- MOS_MIGRATED_REVID=138491791
* Fix help text for --command_port so that it does not refer to the ↵Gravatar Lukacs Berki2016-10-25
| | | | | | | nonexistent AF_UNIX mode. -- MOS_MIGRATED_REVID=137135400
* Allow configuring writing of command.logGravatar Michajlo Matijkiw2016-09-19
| | | | | | | | Sometimes, especially in the case of a lot of output, one may not want to write everything twice. -- MOS_MIGRATED_REVID=133388416
* --Gravatar Luis Fernando Pino Duque2016-08-19
| | | | MOS_MIGRATED_REVID=130747105
* Document --watchfs optionGravatar Dan Fabulich2016-08-08
| | | | | | | -- Change-Id: Id1f37cfe4dcb77a4af0465028f6b17e574b85954 Reviewed-on: https://bazel-review.googlesource.com/#/c/4191/ MOS_MIGRATED_REVID=129442887
* Make the default way of communication between client and the server gRPC ↵Gravatar Lukacs Berki2016-08-01
| | | | | | | instead of AF_UNIX. -- MOS_MIGRATED_REVID=128962306
* Polish the command-line reference.Gravatar Ulf Adams2016-06-27
| | | | | | | | | | | - change options to print --foo=value - allow option to specify what "value" should be - update the documentation for the startup options - add some indentation to the descriptions - add some spacing between flag texts -- MOS_MIGRATED_REVID=125960618
* Set the default value of PRODUCT_NAME to "Bazel" and add a test to guaranteeGravatar Luis Fernando Pino Duque2016-06-24
| | | | | | | Bazel is using the right value. -- MOS_MIGRATED_REVID=125764994
* Update the startup option help texts.Gravatar Ulf Adams2016-06-21
| | | | | -- MOS_MIGRATED_REVID=125436393
* Replace Constants.PRODUCT_NAME with a startup option --product_name=bazel and Gravatar Luis Fernando Pino Duque2016-05-31
| | | | | | | | | | | (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
* Separate killing Bazel on OOM using -XX:OnOutOfMemoryError and ↵Gravatar Janak Ramakrishnan2016-05-24
| | | | | | | | | 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
* Flip --deep_execroot to default to trueGravatar Kristina Chodorow2016-05-11
| | | | | -- MOS_MIGRATED_REVID=121996611
* Make gRPC mode honor --max_idle_secs.Gravatar Lukacs Berki2016-04-25
| | | | | -- MOS_MIGRATED_REVID=120699557
* Assorted changes wrt. gRPC client/server comms:Gravatar Lukacs Berki2016-04-21
| | | | | | | | | - Actually make it work again (commit 00cfb7df61b1f3d9fac8ee29d92b315cbfe6d28f broke it, maybe I shouldn't send out changes in a hurry next time) - Rename --grpc_port to --command_port (it's a bit better name) - Do not send a kill signal to the server that can't be connected if we only connect to it to verify its presence -- MOS_MIGRATED_REVID=120418784
* Add the --grpc_port startup option and start a Java server if it's passed in.Gravatar Lukacs Berki2016-04-14
| | | | | | | | | | | | | Note that the presence of server/grpc_port does not guarantee that the server actually listens to it and we can't guarantee it, either, because it can always be kill -9'd. I haven't decided yet how the transition between AF_UNIX and gRPC will work. For now, I'm happy that we can start up a Java server. The way to get the kernel-chosen port is truly awful, but it is apparently impossible to do so in a different way: https://github.com/grpc/grpc-java/issues/72 -- MOS_MIGRATED_REVID=119828354
* Change --experimental_oom_more_eagerly_threshold default to 100, so that it ↵Gravatar Janak Ramakrishnan2016-03-31
| | | | | | | is a no-op by default. -- MOS_MIGRATED_REVID=118705742
* Add startup option --experimental_oom_more_eagerly_threshold, with default ↵Gravatar Janak Ramakrishnan2016-03-24
| | | | | | | value 90. When --experimental_oom_more_eagerly is enabled, if after two full GCs the old gen is still >=--experimental_oom_more_eagerly_threshold% full, exit the JVM. -- MOS_MIGRATED_REVID=117943361
* Add a new startup option, --experimental_oom_more_eagerly. Features to have ↵Gravatar Janak Ramakrishnan2016-03-08
| | | | | | | Bazel exit more eagerly due to an OOM will be guarded by this flag. -- MOS_MIGRATED_REVID=116567102
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-23 03:51:49 +0000