[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