RFR: 8131330: G1CollectedHeap::verify_dirty_young_list fails with assert

Eric Caspole eric.caspole at oracle.com
Wed Aug 19 17:51:43 UTC 2015

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.

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

More information about the hotspot-gc-dev mailing list