Assertion failure on PPC64 after 8200545: Improve filter for enqueued deferred cards

[Doerr, Martin]

Hi Thomas,

thanks for the webrevs. As discussed offline, I don't think that PPC64 uses word instead of byte accesses.

I can test webrev.test1. This looks like a good idea. Maybe it would also resolve the issue on SPARC when using 8 bit types?
My main concern is that the issue seems to be hard to reproduce, but I'll try to run tests for some time.

Thanks and best regards,
Martin


> -----Original Message-----
> From: Thomas Schatzl <thomas.schatzl at oracle.com>
> Sent: Montag, 27. Mai 2019 12:48
> To: Doerr, Martin <martin.doerr at sap.com>
> Cc: hotspot-gc-dev at openjdk.java.net
> Subject: Re: Assertion failure on PPC64 after 8200545: Improve filter for
> enqueued deferred cards
> 
> Hi Martin,
> 
> On Fri, 2019-05-24 at 16:54 +0200, Thomas Schatzl wrote:
> > Hi,
> >
> > On Fri, 2019-05-24 at 13:48 +0000, Doerr, Martin wrote:
> > > Hi Thomas,
> > >
> > > > The only way I could imagine such an error would be if the
> > > > compiler did something weird with writing the fields of the heap
> > > > attribute table? I.e. it loads a machine word (containing four of
> > > > those RegionAttr entries), modifies just one of the bytes, and
> > > > writes back the whole word. I.e. then some concurrent reader
> > > > might see inconsistent values that flip back and forth.
> > > > I really doubt this is the case though. Particularly I assume
> > > > that at least on ppc64/linux you also use gcc.
> > >
> > >
> [...]
> > I can prepare some change for you to test, making the fields accessed
> > "atomically" (via  e.g. our Atomic::load/store methods, or making
> > them word sized) but I can't really test if it fixes the problem as
> > we've never reproduced this case afaict in our CI. Would that help
> > you?
> 
> Changes:
> http://cr.openjdk.java.net/~tschatzl/8224681/webrev.test1/ uses
> Atomic::load/store to access the G1HeapRegionAttr members only.
> 
> http://cr.openjdk.java.net/~tschatzl/8224681/webrev.test2/ test1 +
> using 32 bit words for the members (64 bit struct). So above problem
> should not happen.
> 
> I will follow up with some memory visibility analysis in the next days.
> 
> Thanks,
>   Thomas