Shenandoah and 11.0.5 backports
Roman Kennke
rkennke at redhat.com
Wed Jul 24 09:12:48 UTC 2019
Since the fixes coming from 11.0.5 only affect performance:
https://bugs.openjdk.java.net/browse/JDK-8224580
and runs with -XX:+EliminateLocks:
https://bugs.openjdk.java.net/browse/JDK-8217990
(if I understand correctly)
... we could also go ahead and push the backports and wait until the
fixes arrive through the usual channels.
Or we could just wait until the fixes arrived via the usual channels.
How long would that take? Could we accept this?
Roman
> Hi,
>
> Some of our Shenandoah/11 backports require changes that are backported in 11.0.5. Unfortunately,
> those changes are not yet in jdk-updates/jdk11u, because the pre-release fork for 11.0.5 had not yet
> started. What can we do at this point?
>
> I see these ways out:
>
> a) Pull jdk-updates/jdk11u-dev (notice -dev) to sh/jdk11. This goes against our usual process of
> only pulling from "stable" jdk-updates/jdk11u. The upside is that we don't have to coordinate. The
> downside is we would temporarily "leak" all non-stable backports that are currently destined to
> 11.0.5 into our "integration repo".
>
> b) Cherry-pick required changes to sh/jdk11, and then wait for the final merge to render the
> difference against upstream nil. The upside is that we are completely isolated from upstream
> processes. The downside is that we would have double changesets after all this is done, and also we
> would temporarily "leak" some backports from 11.0.5 into our "integration repo".
>
> c) Ask 11u updates project to tag 11.0.5+1 and push it to jdk-updates/jdk11u, then we pick it up
> via the regular channel. The upside is that this path would not be exceptional. The downside is that
> we would need to coordinate such a push in upstream.
>
> I am leaning towards (a), then (b), then (c). Opinions?
>
>
More information about the shenandoah-dev
mailing list