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

Volker Simonis volker.simonis at gmail.com
Fri May 16 08:12:46 UTC 2014


I've updated "8042930: Consider removing UseMemSetInBOT"
(https://bugs.openjdk.java.net/browse/JDK-8042930) with the below
comments to document the problem we had with SPARC CPU detection for


When we really remove UseMemSetInBOT we should pay close attention to
also consider other SPARC CPUs like for example Fujitsu Sparc64-X

The following mail threads and bugs discussed the problems of checking
the relevant CPU-features on Fujitsu CPUs

"CPU-feature detection is broken for new Fujitsu Sparc64-X CPUs"

"RFR(S): 8029190 : VM_Version::determine_features() asserts on Fujitsu
Sparc64 CPUs"

"VM_Version::determine_features() asserts on Fujitsu Sparc64 CPUs"

I think we still couldn't find out until now how memset() is
implemented on Solaris/Fujitsu Sparc-X and/or how BIS is working on
Fujitsu Sparc-X.

On Thu, May 15, 2014 at 12:01 AM, Vladimir Kozlov
<vladimir.kozlov at oracle.com> wrote:
> Jon,
> We already do that for UseMemSetInBOT flag in vm_version_sparc.cpp. And it
> is correctly use has_blk_init() check because is_T4() is not reliable.
> Vladimir
> On 5/14/14 1:34 PM, Jon Masamitsu wrote:
>> Per,
>> Could you use a check on the sparc version to decide
>> on when to use memset.
>> VM_Version::is_T4()
>> in cpu/sparc/vm/vm_version_sparc.hpp
>> Jon
>> On 5/13/2014 3:34 AM, 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/
>>> Thanks!
>>> /Per

More information about the hotspot-gc-dev mailing list