RFR(S): 8039042: G1: Phantom zeros in cardtable

Thomas Schatzl thomas.schatzl at oracle.com
Tue May 20 07:06:29 UTC 2014


Hi,

On Tue, 2014-05-20 at 08:19 +0200, Per Liden wrote:
> Thanks for reviewing Mikael, and thanks for the co-debugging this. 
> Indeed an interesting bug :)
> 
> Still looking for a capital R review on this patch.
> 
> Thanks!
> /Per
> 
> On 05/13/2014 02:41 PM, Mikael Gerdin wrote:
> > Per,
> >
> > On Tuesday 13 May 2014 12.34.25 Per Liden wrote:
> >> Summary: We use memset to initialize the cardtable. On Sparc T4 (and
> >> later) memset uses some special instructions with the side-effect that
> >> the memory can temporarily be filled with zeros before the actual value
> >> is set. These phantom zeros can be observed by concurrent readers of
> >> this memory, which can trick the G1 post-barrier to incorrectly dirty a
> >> card in a young region. Please see the bug for a more details.
> >>
> >> A similar memset-problem has been observed and fixed before
> >> (JDK-6948537) when using memset on the BlockOffsetTable. Similar to the
> >> BlockOffsetTable, I'm using the UseMemSetInBOT flag as an indicator of
> >> whether it's safe to use memset or not. UseMemSetInBOT is not a perfect
> >> name for this flag as code other than the BOT might want to use it. It's
> >> also questionable of this should be a command-line flag at all. I've
> >> filed a separate RFE, JDK-8042930, to do a bit of clean up related to
> >> this flag.
> >>
> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8039042
> >> Webrev: http://cr.openjdk.java.net/~pliden/8039042/webrev.0/

  looks good.

Thomas




More information about the hotspot-gc-dev mailing list