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

[Per Liden]

Thanks, good information there. Just to avoid any potential 
misunderstands around the RFE I filled. I'm basically just saying we 
should consider not exposing this as a command like flag, but we 
obviously need to keep it (with a better name) as an internal flag 
somewhere.

cheers,
/Per

On 2014-05-16 10:12, Volker Simonis wrote:
> Hi,
>
> 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.
>
> Regards,
> Volker
>
>
> 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"
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-November/thread.html#11834
>
> "RFR(S): 8029190 : VM_Version::determine_features() asserts on Fujitsu
> Sparc64 CPUs"
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-December/thread.html#11892
>
> "VM_Version::determine_features() asserts on Fujitsu Sparc64 CPUs"
> https://bugs.openjdk.java.net/browse/JDK-8029190
>
> 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
>>>