RFR: 8131330: G1CollectedHeap::verify_dirty_young_list fails with assert

[Eric Caspole]

Hi Kim,
Is it allowed to use a more descriptive label name than 1,2,3 in the 
sparc inline asm? I expect this works fine and no one will ever look at 
it again but just in case, I think it is easier to read and see the use 
of the labels if it is a descriptive word.
The rest of it looks good.
Thanks,
Eric


On 08/19/2015 01:10 PM, Kim Barrett wrote:
> Please review this fix for a recurrence of a problem with certain uses
> of memset on SPARC platforms [1][2].
>
> This change adds a helper function, memset_with_concurrent_readers,
> for use by G1 and CMS in situations where a memory region is to be
> filled while there may be concurrent readers of that region.  This
> function is implemented by simply forwarding to memset on most
> platforms.  On SPARC, this function avoids calling memset, because
> that function may be implemented using block initialization stores,
> which lead to the problems described in [1] and [2].
>
> As part of this change we also eliminate the UseMemSetInBOT
> experimental command line option, thereby resolving [3].
>
> The SPARC implementation of memset_with_concurrent_readers is written
> using inline assembly code rather than a C++ for-loop, because the
> compiler may recognize the for-loop and transform it into a call to
> memset, undoing our intentional avoidance of memset.  We see exactly
> this happening with Solaris Studio 12.3, for example.  It is this
> transformation that led to this recurrence of the problem from [1][2].
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8131330
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8131330/webrev.00/
>
> Testing:
> jprt
> aurora ad hoc GC/Runtime Nightly, quicktests, tonga, jtreg
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8039042
> [2] https://bugs.openjdk.java.net/browse/JDK-6948537
> [3] https://bugs.openjdk.java.net/browse/JDK-8042930
>