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

[Doerr, Martin]

Hi Thomas,

there's an important update:
The problem showed up on linuxx64_64, too.

Attached hs_err_pid67024.log to the bug.
Test was api/java_text/NumberFormat/UnicodeExtensions from jck suite.

Best regards,
Martin


> -----Original Message-----
> From: Doerr, Martin
> Sent: Montag, 27. Mai 2019 14:26
> To: Thomas Schatzl <thomas.schatzl at oracle.com>
> Cc: hotspot-gc-dev at openjdk.java.net
> Subject: RE: Assertion failure on PPC64 after 8200545: Improve filter for
> enqueued deferred cards
> 
> 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