RFR(S): 8039042: G1: Phantom zeros in cardtable
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
FUJITSU Sparc64-X CPUs.
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
"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
On Thu, May 15, 2014 at 12:01 AM, Vladimir Kozlov
<vladimir.kozlov at oracle.com> wrote:
> 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.
> On 5/14/14 1:34 PM, Jon Masamitsu wrote:
>> Could you use a check on the sparc version to decide
>> on when to use memset.
>> in cpu/sparc/vm/vm_version_sparc.hpp
>> 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/
More information about the hotspot-gc-dev