[aarch64-port-dev ] RFR 8135018: AARCH64: Missing memory barriers for CMS collector
Yangfei (Felix)
felix.yang at huawei.com
Mon Dec 16 03:43:34 UTC 2019
Hi Liu Xin,
Thanks for finding this. Looks like the new backport patch still mixed code changes from JDK-8076987. Does that brings any side-effect?
Normally, I prefer backporting JDK-8076987 & JDK-8078438 to jdk8u-dev first. Then, they will be merged to jdk8u-shenandoah after some time.
After that, we can do a clean backport of JDK-8076987 for jdk8u-shenandoah.
I always try to go this way when my backport patch changed shared code. It should help reduce the complexity for merging from jdk8u-dev to jdk8u-shenandoah.
Felix
> -----Original Message-----
> From: aarch64-port-dev [mailto:aarch64-port-dev-bounces at openjdk.java.net]
> On Behalf Of Andrew Haley
> Sent: Sunday, December 15, 2019 6:18 AM
> To: Liu Xin <navy.xliu at gmail.com>
> Cc: Doerr, Martin <martin.doerr at sap.com>;
> aarch64-port-dev at openjdk.java.net
> Subject: Re: [aarch64-port-dev ] RFR 8135018: AARCH64: Missing memory
> barriers for CMS collector
>
> On 12/14/19 4:47 AM, Liu Xin wrote:
> > I trace the feature UseCondCardMark. It was introduced by the
> > following changes.
> > https://bugs.openjdk.java.net/browse/JDK-8076987 C1
> > https://bugs.openjdk.java.net/browse/JDK-8078438 interpreter
> > UseCondCardMark is only supported by C2 currently. Yes, my original
> > patch does miss hunk -- the x86 part. That's why I propose a new webrev
> here.
> > It's almost a clean backport for JDK-8135018. Let's solve the missing
> > barrier bug first. Could you take a look at it?
> > https://cr.openjdk.java.net/~xliu/8135018/01/webrev/
>
> That's OK, thanks.
>
> --
> Andrew Haley (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the aarch64-port-dev
mailing list