JDK-8132233 : Provide the option to disable conditional card marking in G1
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P4
  • Status: Resolved
  • Resolution: Won't Fix
  • Submitted: 2015-07-23
  • Updated: 2017-04-24
  • Resolved: 2017-04-24
Description
Since JDK-8014555, G1 post-barrier contains a StoreLoad barrier between the oop store and the card mark load. This is required to maintain the proper memory ordering in the face of conditional card mark updates. However, in some cases that barrier gets into the way. While it is an open question if we can optimize the barrier itself out, it makes sense to make G1 respond to UseCondCardMark, and thus provide the ability for users to avoid the barrier by disabling conditional card marks. (Hoping that pre-checks in G1 post-barrier filter enough card mark updates). 

UseCondCardMark is disabled by default, but we can turn enable it by default with UseG1GC, so that the default behavior is the same.
Comments
Marking as WNF. It seems the better solution would be implementing G1 throughput barriers that avoid this conc refinement race altogether.
24-04-2017
Doug Lea had been fighting with G1 for weeks now, to conclude the FJP progress on large machines basically bottlenecks on MFENCEs in G1 post_barrier. Which leads me to believe disabling cond card mark could help to verify/triage.
24-07-2015
Just a question, how does that change "helps triaging of G1-specific performance bugs"? Did you find a case (that FJ micro) where this actually improves throughput?
23-07-2015
webrev.00 passes JPRT with either out of box options, or -XX:-UseCondCardMark.
23-07-2015
Yes, my hope is that the additional checks filter enough events to make the overhead of actual unconditional card marking bearable. Either way, making G1 to respond to already available UseCondCardMark helps triaging of G1-specific performance bugs (like we are doing now with G1/FJP saga). That alone, I think, warrants the change.
23-07-2015
I tried a variant of this when investigating JDK-8014555 and came to the conclusion that completely disabling the conditional card marking (which was an alternate approach to solving that particular bug) made the per thread dirty card buffers (and thus conc refinement) to blow up due to a lot of duplicated cards being enqueued. I did not investigate the effect of keeping the young_card_val conditional and unconditionally enqueueing cards covering non-young regions.
23-07-2015
Proof-of-concept for x86: http://cr.openjdk.java.net/~shade/8132233/webrev.00/
23-07-2015