Closed marko-asplund closed 3 years ago
I think you probably meant to file this at https://github.com/AdoptOpenJDK/openjdk-docker/issues (from https://hub.docker.com/_/adoptopenjdk); the OpenJDK 11 builds for this image (https://hub.docker.com/_/openjdk) come from https://adoptopenjdk.net/upstream.html, but they are vanilla OpenJDK builds (not AdoptOpenJDK builds -- they're simply hosted/sponsored by the AdoptOpenJDK project).
See also https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries/releases for where the latest available build is the 11.0.9 build from Oct 20 which we updated to in https://github.com/docker-library/openjdk/commit/a1056a406c11909319b95a9631933cdc2035005a.
Yes, I was incorrectly referencing the AdoptOpenJDK build here.
Still, according to OpenJDK wiki Shenandoah should be in mainline builds:
In mainline OpenJDK 11u builds since 11.0.9.
🤔 So, shouldn't Shenandoah be included in openjdk:11-jre-buster
?
~ % docker run -it openjdk:11-jre-buster
root@fa33b9a3d0e2:/#
root@fa33b9a3d0e2:/# java --version
openjdk 11.0.9 2020-10-20
OpenJDK Runtime Environment 18.9 (build 11.0.9+11)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.9+11, mixed mode)
root@fa33b9a3d0e2:/#
root@fa33b9a3d0e2:/# java -XX:+UseShenandoahGC -Xlog:gc -version
Unrecognized VM option 'UseShenandoahGC'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
I also tried downloading a JRE binary package from https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries/releases but that doesn't appear to include the Shenandoah either:
root@fa33b9a3d0e2:/tmp# wget -q https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries/releases/download/jdk-11.0.9%2B11/OpenJDK11U-jre_x64_linux_11.0.9_11.tar.gz
root@fa33b9a3d0e2:/tmp# tar zxf OpenJDK11U-jre_x64_linux_11.0.9_11.tar.gz
root@fa33b9a3d0e2:/tmp# ./openjdk-11.0.9_11-jre/bin/java -version
openjdk version "11.0.9" 2020-10-20
OpenJDK Runtime Environment 18.9 (build 11.0.9+11)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.9+11, mixed mode)
root@fa33b9a3d0e2:/tmp# ./openjdk-11.0.9_11-jre/bin/java -XX:+UseShenandoahGC -Xlog:gc -version
Unrecognized VM option 'UseShenandoahGC'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Looks like https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries/issues/11, and specifically https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries/issues/11#issuecomment-717116367 is the missing context here (thanks for initiating that conversation :smile:).
To unpack that a little, the end result is that for us to add a separate variant with Shenandoah for OpenJDK 11, we'd be looking at 12 additional builds (and 126 additional tags) above our already very complex 46-build support matrix (not to mention the added variable of supported architectures). :disappointed:
(If you want a taste of the level of complexity, try to review the templating change in #450 which I imagine will hurt anyone's brain to read/review just as much as it hurt mine to write :weary:)
On the flip side, making a build for yourself should be a pretty trivial change to our existing Dockerfile
s -- choose the variant you're interested in and swap out OpenJDK11U-jdk_xxx_11.xxx.tar.gz
for OpenJDK11U-jdk-shenandoah_xxx_11.xxx.tar.gz
and you should be mostly up and running!
What you could do, is like you said, swap the non-shenandoah enabled OpenJDK for the shenandoah enabled one in the openjdk docker images. They should be identical other than the extra GC. Your call!
While it's an interesting idea from a user perspective (IMO), I think we'd have to object on the same grounds that the folks building these artifacts we're consuming did -- we've been openly yelled at by the OpenJDK community for a lot less than swapping out the "default" GC implementation for an optional non-default one, so I'd be very hesitant to make any changes that don't align with the upstream OpenJDK default settings. :grimacing: :disappointed:
Sure, that's fine. To give you all the data, though: By swapping that artefact you are not swapping the default GC. That would be hugely disruptive. You'd be swapping a JVM which doesn't have Shenandoah as a GC option (must be enabled with -XX:+UseShenandoahGC
) to a JVM which has that additional GC available (it still must be enabled with said option).
Since the 11 images here are "vanilla OpenJDK", and so follow https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries/releases, we'll not be switching that artifact to use the "non-vanilla" Shenandoah-enabled one.
If Shenandoah is needed, either build your own image as described in this thread by swapping the artifact URL, or use another JDK that does enable it (adoptopenjdk
, or amazoncorretto
are likely candidates from https://wiki.openjdk.java.net/display/shenandoah/Main#Main-Releases)
Shenandoah GC was not included with the OpenJDK v11.0.9 build released last week. https://github.com/AdoptOpenJDK/openjdk-build/issues/2176
A new 11.0.9 build has just been made available that fixes this issue.
Could you please update the Docker images to include the new build - thanks! 👍