-
Notifications
You must be signed in to change notification settings - Fork 476
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
Shenandoah GC not available in v11.0.9 #437
Comments
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 a1056a4. |
Yes, I was incorrectly referencing the AdoptOpenJDK build here. Still, according to OpenJDK wiki Shenandoah should be in mainline builds:
🤔 So, shouldn't Shenandoah be included in
|
I also tried downloading a JRE binary package from https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries/releases
|
Looks like AdoptOpenJDK/openjdk11-upstream-binaries#11, and specifically AdoptOpenJDK/openjdk11-upstream-binaries#11 (comment) is the missing context here (thanks for initiating that conversation 😄). |
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). 😞 (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 😩) On the flip side, making a build for yourself should be a pretty trivial change to our existing |
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. 😬 😞 |
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 |
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 ( |
Shenandoah GC was not included with the OpenJDK v11.0.9 build released last week.
adoptium/temurin-build#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! 👍
The text was updated successfully, but these errors were encountered: