Patch release #5786
Closed
Patch release #5786
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The JDK9 compressed binary size increased to ~200MiB from ~85MiB in JDK8. We built a JDK reduced in size to ~50MiB, that still ships with a full set of APIs. See https://docs.google.com/document/d/1Igmv-2GfXkoVFWTXvBYPeniQom8nLAwzqzridDlBIS4 for more details. Commands to build the Linux JDK: curl https://mirror.bazel.build/openjdk/azul-zulu-9.0.7.1-jdk9.0.7/zulu9.0.7.1-jdk9.0.7-linux_x64.tar.gz -o zulu9.0.7.1-jdk9.0.7-linux_x64.tar.gz tar -xf zulu9.0.7.1-jdk9.0.7-linux_x64.tar.gz cd zulu9.0.7.1-jdk9.0.7-linux_x64/ ./bin/jlink --module-path ./jmods/ --add-modules java.activation,java.base,java.compiler,java.corba,java.datatransfer,java.desktop,java.instrument,java.logging,java.management,java.management.rmi,java.naming,java.prefs,java.rmi,java.scripting,java.se,java.se.ee,java.security.jgss,java.security.sasl,java.smartcardio,java.sql,java.sql.rowset,java.transaction,java.xml,java.xml.bind,java.xml.crypto,java.xml.ws,java.xml.ws.annotation,jdk.accessibility,jdk.aot,jdk.attach,jdk.charsets,jdk.compiler,jdk.crypto.cryptoki,jdk.crypto.ec,jdk.dynalink,jdk.editpad,jdk.hotspot.agent,jdk.httpserver,jdk.incubator.httpclient,jdk.internal.ed,jdk.internal.jvmstat,jdk.internal.le,jdk.internal.opt,jdk.internal.vm.ci,jdk.internal.vm.compiler,jdk.jartool,jdk.javadoc,jdk.jcmd,jdk.jconsole,jdk.jdeps,jdk.jdi,jdk.jdwp.agent,jdk.jlink,jdk.jshell,jdk.jsobject,jdk.jstatd,jdk.localedata,jdk.management,jdk.management.agent,jdk.naming.dns,jdk.naming.rmi,jdk.net,jdk.pack,jdk.policytool,jdk.rmic,jdk.scripting.nashorn,jdk.scripting.nashorn.shell,jdk.sctp,jdk.security.auth,jdk.security.jgss,jdk.unsupported,jdk.xml.bind,jdk.xml.dom,jdk.xml.ws,jdk.zipfs --vm=server --strip-debug --no-man-pages --output zulu9.0.7.1-jdk9.0.7-linux_x64-allmodules cp DISCLAIMER readme.txt zulu9.0.7.1-jdk9.0.7-linux_x64-allmodules/ GZIP=-9 tar -zcf ./zulu9.0.7.1-jdk9.0.7-linux_x64-allmodules.tar.gz zulu9.0.7.1-jdk9.0.7-linux_x64-allmodules RELNOTES: None PiperOrigin-RevId: 202948182
…uild#5491 This change limits the number of open tcp connections by default to 100 for remote caching. We have had error reports where some use cases Bazel would open so many TCP connections that it crashed/ran out of sockets. The max. number of TCP connections can still be adjusted by specifying --remote_max_connections. See also bazelbuild#5047. RELNOTES: In remote caching we limit the number of open TCP connections to 100 by default. The number can be adjusted by specifying the --remote_max_connections flag. PiperOrigin-RevId: 202958838
Flags passed through clang to linker get -Wl, stripped in the error message (e.g. -Wl,-no-as-needed will be reported as "ld: unknwon option: -no-as-needed"). This cl fixes the autodetection to expect the stripped variant. Fixes bazelbuild#5468. RELNOTES: None. PiperOrigin-RevId: 203341563
Clang reports missing -Wl,-z,relro as "ld: unknwon option: -z"). This cl fixes the autodetection to expect the short variant. Fixes bazelbuild#5468. RELNOTES: NONE. PiperOrigin-RevId: 203449206
On some systems (including some versions of FreeBSD) it is a requirement that _WITH_DPRINTF be defined for <stdio.h> to provide the appropriate header for dprintf(3). Therefore, the respective #define has to come before any #include as those might pull is <stdio.h>. Change-Id: I25d55c9c7c0912e8619faf774d2e09f9af9a6a53 PiperOrigin-RevId: 203351202
...as this file uses blaze_util::JoinPath. Apparently, until recently, that header file was pulled in indirectly, so that this wasn't detected until now. Nevertheless, the header files for functions used directly should also be included explicitly anyway. Change-Id: Id181480c6ec7fd146ce8b7b00980319f13c3f518 PiperOrigin-RevId: 203445044
I missed the java.instrument module when building the smaller openjdk. I have updated the jdk to include this module. This was the cause for bazelbuild#5532. The image was created by https://buildkite.com/bazel/build-embedded-jdk/builds/23 RELNOTES: None PiperOrigin-RevId: 203797576
Also correct for buggy profiles written previously. RELNOTES: None. PiperOrigin-RevId: 202920255
For downloading output files / directories we trigger all downloads concurrently and asynchronously in the background and after that wait for all downloads to finish. However, if a download failed we did not wait for the remaining downloads to finish but immediately started deleting partial downloads and continued with local execution of the action. That leads to two interesting bugs: * The cleanup procedure races with the downloads that are still in progress. As it tries to delete files and directories, new files and directories are created and that will often lead to "Directory not empty" errors as seen in bazelbuild#5047. * The clean up procedure does not detect the race, succeeds and subsequent local execution fails because not all files have been deleted. The solution is to always wait for all downloads to complete before entering the cleanup routine. Ideally we would also cancel all outstanding downloads, however, that's not as straightfoward as it seems. That is, the j.u.c.Future API does not provide a way to cancel a computation and also wait for that computation actually having determinated. So we'd need to introduce a separate mechanism to cancel downloads. RELNOTES: None PiperOrigin-RevId: 205980446
When switching to JDK9 we regressed on java build performance by about ~30%. We found that when using parallel gc instead of G1 and disabling compact strings for JavaBuilder, the java build performance is "only" 10% slower. We additionally found JDK9 to have a significantly higher startup time. This impacts the performance of tools like javac and tubine and we believe that this accounts for most of the remaining overhead that can't be explained by disabling G1 and compact strings. java8 -version: 80ms java9 -version: 140ms java10 -version: 110ms Additionally, we found that the number of modules shipped with the JDK have a direct effect on the startup time. When building Java 10 with only the 9 modules required by Bazel we find that the startup time reduces to 80ms (from 110ms) which is on par with Java 8. We thus expect the regression to be fixed by a future migration to Java 10, which should be done in one of the next Bazel releases. == Some benchmark results == https://github.com/google/protobuf $ bazel build :protobuf_java Bazel 0.15.2: 4.2s Bazel 0.16.0-rc2: 5.2s This Change: 4.2s https://github.com/jin/android-projects/tree/master/java_only $ bazel build :module0 Bazel 0.15.2: 8.2s Bazel 0.16.0-rc2: 11.5s This Change: 9.1s RELNOTES: None PiperOrigin-RevId: 205647957
Baseline: 4f64b77 Cherry picks: + 4c9a0c8: reduce the size of bazel's embedded jdk + d3228b6: remote: limit number of open tcp connections by default. Fixes bazelbuild#5491 + 8ff87c1: Fix autodetection of linker flags + c4622ac: Fix autodetection of -z linker flags + 1021965: blaze_util_posix.cc: fix order of #define + ab1f269: blaze_util_freebsd.cc: include path.h explicitly + 68e92b4: openjdk: update macOS openjdk image. Fixes bazelbuild#5532 + f45c224: Set the start time of binary and JSON profiles to zero correctly. + bca1912: remote: fix race on download error. Fixes bazelbuild#5047 + 3842bd3: jdk: use parallel old gc and disable compact strings Incompatible changes: - The $(ANDROID_CPU) Make variable is not available anymore. Use $(TARGET_CPU) after an Android configuration transition instead. - The $(JAVA_TRANSLATIONS) Make variable is not supported anymore. - Skylark structs (using struct()) may no longer have to_json and to_proto overridden. - The mobile-install --skylark_incremental_res flag is no longer available, use the --skylark flag instead. New features: - android_local_test now takes advantage of Robolectric's binary resource processing which allows for faster tests. - Allow @ in package names. Important changes: - Option --glibc is removed, toolchain selection relies solely on --cpu and --compiler options. - Build support for enabling cross binary FDO optimization. - The --distdir option is no longer experimental. This option allows to specify additional directories to look for files before trying to fetch them from the network. Files from any of the distdirs are only used if a checksum for the file is specified and both, the filename and the checksum, match. - Java coverage works now with multiple jobs. - Flip default value of --experimental_shortened_obj_file_path to true, Bazel now generates short object file path by default. - New rules for importing Android dependencies: `aar_import_external` and `aar_maven_import_external`. `aar_import_external` enables specifying external AAR dependencies using a list of HTTP URLs for the artifact. `aar_maven_import_external` enables specifying external AAR dependencies using the artifact coordinate and a list of server URLs. - The BAZEL_JAVAC_OPTS environment variable allows arguments, e.g., "-J-Xmx2g", may be passed to the javac compiler during bootstrap build. This is helpful if your system chooses too small of a max heap size for the Java compiler during the bootstrap build. - --noexpand_configs_in_place is deprecated. - A tool to parse the Bazel execution log. - Support for LIPO has been fully removed. - Remove support for --discard_actions_after_execution. - Add --materialize_param_files flag to write parameter files even when actions are executed remotely. - Windows default system bazelrc is read from the user's ProgramData if present. - --[no]allow_undefined_configs no longer exists, passing undefined configs is an error. - In remote caching we limit the number of open TCP connections to 100 by default. The number can be adjusted by specifying the --remote_max_connections flag.
This reverts commit dbe5efe.
This reverts commit f6dbc5e.
This reverts commit 9dabbb1.
This reverts commit 7c49bd9.
This reverts commit 72141a1.
|
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. |
ola-rozenfeld
approved these changes
Aug 7, 2018
This was referenced Aug 7, 2018
|
I'm closing this, although I'm not sure what it's good for. Feel free to reopen if there's still something here. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.