-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update embedded JDK to 11 to fix a host of docker related issues #6592
Comments
Related: #6661. |
@Monnoroch There's no requirement anymore to have the same embedded JDK version as we use for the host javabase so #6661 is talking about updating the JDK version, it's a different JDK. Independently, we also plan to upgrade the embedded JDK after we have submitted some other changes and hopefully it'll land before we cut 0.22. If I understand the new java container support correctly, you probably still want to set a JVM flag in the container. The JVM uses by default 1/4 of the physical available memory for the heap. In a container, you may have less memory available than what's physically in your machine. Now, if the heap grows too large, Bazel gets killed. With the new container support, the "physical available memory" is limited to the memory available in the container. Thus, the heap will not grow too large, but it's using 1/4 of the available memory. That may not be enough and you might want to set MaxRamFraction in your CI environment. |
I tried 0.22rc2 yesterday and it is still using JDK 9. |
David, that's correct. I wasn't able to properly test and land the changes mostly because of holidays. I'll definitely do it before 0.23. |
@meisterT Thanks. Let me know, if you have a commit somewhere. I would be happy to build Bazel from scratch and test it against Gerrit Code Review and related projects. |
This builds the minimal JDK locally and uses it as embedded JDK. We typically use the cached one on mirror.bazel.build, because the jlink is heavily non-determistic. However, this will make local testing easier, e.g. when we do upgrades from one JDK to another. Progress on bazelbuild#6592 and bazelbuild#6314. RELNOTES: None
This builds the minimal JDK locally and uses it as embedded JDK. We typically use the cached one on mirror.bazel.build, because the jlink is heavily non-determistic. However, this will make local testing easier, e.g. when we do upgrades from one JDK to another. Progress on bazelbuild#6592 and bazelbuild#6314. RELNOTES: None Closes bazelbuild#7175. PiperOrigin-RevId: 229912262
We want to upgrade the embedded JDK to version 11 (see bazelbuild#6592). However, some Java EE modules were removed from 10 to 11: http://openjdk.java.net/jeps/320 From these modules, we need java.xml.bind for the android_common dependency which is used by the android_sdk_repository rule. This will be starlark-ified some time in the future and then will also move the tools to an external repository making it possible to remove this and the android_common dependency from Bazel. But since the migration is not imminent, this commit is the work around to unblock the upgrade to JDK11. RELNOTES: None
We want to upgrade the embedded JDK to version 11 (see bazelbuild#6592). However, some Java EE modules were removed from 10 to 11: http://openjdk.java.net/jeps/320 From these modules, we need java.xml.bind for the android_common dependency which is used by the android_sdk_repository rule. This will be starlark-ified some time in the future and then will also move the tools to an external repository making it possible to remove this and the android_common dependency from Bazel. But since the migration is not imminent, this commit is the work around to unblock the upgrade to JDK11. RELNOTES: None
We want to upgrade the embedded JDK to version 11 (see bazelbuild#6592). However, some Java EE modules were removed from 10 to 11: http://openjdk.java.net/jeps/320 From these modules, we need java.xml.bind for the android_common dependency which is used by the android_sdk_repository rule. This will be starlark-ified some time in the future and then will also move the tools to an external repository making it possible to remove this and the android_common dependency from Bazel. But since the migration is not imminent, this commit is the work around to unblock the upgrade to JDK11. RELNOTES: None
We want to upgrade the embedded JDK to version 11 (see bazelbuild#6592). However, some Java EE modules were removed from 10 to 11: http://openjdk.java.net/jeps/320 From these modules, we need java.xml.bind for the android_common dependency which is used by the android_sdk_repository rule. This will be starlark-ified some time in the future and then will also move the tools to an external repository making it possible to remove this and the android_common dependency from Bazel. But since the migration is not imminent, this commit is the work around to unblock the upgrade to JDK11. RELNOTES: None
We want to upgrade the embedded JDK to version 11 (see bazelbuild#6592). However, some Java EE modules were removed from 10 to 11: http://openjdk.java.net/jeps/320 From these modules, we need java.xml.bind for the android_common dependency which is used by the android_sdk_repository rule. This will be starlark-ified some time in the future and then will also move the tools to an external repository making it possible to remove this and the android_common dependency from Bazel. But since the migration is not imminent, this commit is the work around to unblock the upgrade to JDK11. RELNOTES: None
We want to upgrade the embedded JDK to version 11 (see #6592). However, some Java EE modules were removed from 10 to 11: http://openjdk.java.net/jeps/320 From these modules, we need java.xml.bind for the android_common dependency which is used by the android_sdk_repository rule. This will be starlark-ified some time in the future and then will also move the tools to an external repository making it possible to remove this and the android_common dependency from Bazel. But since the migration is not imminent, this commit is the work around to unblock the upgrade to JDK11. RELNOTES: None Partial commit for third_party/*, see #7240. Signed-off-by: Philipp Wollermann <philwo@google.com>
With this we can also build the allmodules JDK in the buildkite pipeline. This is a necessary step for the upgrade to JDK 11, see bazelbuild#6592 and bazelbuild#6314. RELNOTES: None
With this we can also build the allmodules JDK in the buildkite pipeline. This is a necessary step for the upgrade to JDK 11, see bazelbuild#6592 and bazelbuild#6314. RELNOTES: None
Note that this does NOT yet update the embbedded JDKs, this will be one of the next steps after we actually build it on buildkite. Part of bazelbuild#6592. RELNOTES: None
This builds the minimal JDK locally and uses it as embedded JDK. We typically use the cached one on mirror.bazel.build, because the jlink is heavily non-determistic. However, this will make local testing easier, e.g. when we do upgrades from one JDK to another. Progress on bazelbuild#6592 and bazelbuild#6314. RELNOTES: None Closes bazelbuild#7175. PiperOrigin-RevId: 229912262
We want to upgrade the embedded JDK to version 11 (see bazelbuild#6592). However, some Java EE modules were removed from 10 to 11: http://openjdk.java.net/jeps/320 From these modules, we need java.xml.bind for the android_common dependency which is used by the android_sdk_repository rule. This will be starlark-ified some time in the future and then will also move the tools to an external repository making it possible to remove this and the android_common dependency from Bazel. But since the migration is not imminent, this commit is the work around to unblock the upgrade to JDK11. RELNOTES: None Partial commit for third_party/*, see bazelbuild#7240. Signed-off-by: Philipp Wollermann <philwo@google.com>
With this we can also build the allmodules JDK in the buildkite pipeline. This is a necessary step for the upgrade to JDK 11, see bazelbuild#6592 and bazelbuild#6314. RELNOTES: None Closes bazelbuild#7287. PiperOrigin-RevId: 231398365
Note that this does NOT yet update the embbedded JDKs, this will be one of the next steps after we actually build it on buildkite. Part of bazelbuild#6592. Closes bazelbuild#7284. PiperOrigin-RevId: 231578167
While testing Bazel with the upgraded embedded JDK we hit a bug which was fixed by 11.0.2: See https://www.oracle.com/technetwork/java/javase/11-0-2-relnotes-5188746.html for the release notes which lists https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8211883 as fixed. The problem showed e.g. in our integration tests where we download protobuf as external repository from github and we would show an handshake error: ERROR: [...]/BUILD:1:1: every rule of type proto_library implicitly depends upon the target '@com_google_protobuf//:protoc', but this target could not be found because of: no such package '@com_google_protobuf//': java.io.IOException: Error downloading [https://github.com/google/protobuf/archive/7b28271a61a3da0a37f6fda399b0c4c86464e5b3.zip] to [...].zip: Received fatal alert: handshake_failure Note that this commit does not the update of the embedded JDK yet. Part of #6592. RELNOTES: None Closes #7335. PiperOrigin-RevId: 232175766
Description of the problem / feature request:
As far as I can tell bazel is currently coming embedded with openjdk 9 and it is having issues with easily running out of memory in docker containers (most prominently CircleCI it seems), or more generically not respecting cgroups for resource limits.
issues I could find that seem releated:
#3886
#4616
#5180
#3645
#5389
bazelbuild/rules_docker#520
Feature requests: what underlying problem are you trying to solve with this feature?
It turns out OpenJDK 10 comes with a host of fixes that would improve that situation and for us also just seemed to have solved an issue with using CircleCI. I installed bazel pointing at jdk 11 using
startup --server_javabase /usr/lib/jvm/java-11-openjdk-amd64/"
in the bazelrc, removed any flags aroundlocal_resources
and builds that would continuously fail before are now working, in fact I had a build that would even fail withlocal_resources
and-Xmx3072m
set, but pointing bazel to use jdk 11 fixed that.Here the links to the openjdk issues:
https://bugs.openjdk.java.net/browse/JDK-8196595
https://bugs.openjdk.java.net/browse/JDK-8146115
https://bugs.openjdk.java.net/browse/JDK-8170888
https://bugs.openjdk.java.net/browse/JDK-8140793
Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Probably not that easy to reproduce, but I know rules_nodejs use circleci and had similar issues in the past that where solved with setting the same flags here: https://github.com/bazelbuild/rules_nodejs/blob/master/.circleci/bazel.rc#L17
So maybe they would be a good test case, trying to remove the flags and see if the situation improves. cc @alexeagle
What operating system are you running Bazel on?
Ubuntu 18.04, the docker images are running on debian stretch
What's the output of
bazel info release
?release 0.19.0
Have you found anything relevant by searching the web?
Yep, see issues linked above.
The text was updated successfully, but these errors were encountered: