docker-library / openjdk

Docker Official Image packaging for EA builds of OpenJDK from Oracle
http://openjdk.java.net
MIT License
1.14k stars 475 forks source link

Shenandoah GC not available in v11.0.9 #437

Closed marko-asplund closed 3 years ago

marko-asplund commented 3 years ago

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! 👍

tianon commented 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.

marko-asplund commented 3 years ago

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.
marko-asplund commented 3 years ago

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.
tianon commented 3 years ago

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:).

tianon commented 3 years ago

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 Dockerfiles -- 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!

jerboaa commented 3 years ago

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!

tianon commented 3 years ago

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:

jerboaa commented 3 years ago

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).

yosifkit commented 3 years ago

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)