JDK-8225716 : G1 GC: Undefined behaviour in G1BlockOffsetTablePart::block_at_or_preceding
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 8u212,11.0.3
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2019-06-13
  • Updated: 2020-06-09
  • Resolved: 2019-06-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13 JDK 14 JDK 8 Other
11.0.4Fixed 13 b26Fixed 14Fixed 8u261Fixed openjdk8u222Fixed
Related Reports
Relates :  
The Block Offset Table is accessed racily in many places. This is UB, but I suspect the authors of G1 assumed that the UB was "benign". In fact it is not, and there is a narrow race condition which causes G1 to crash at times of heavy stress.

The bug has only ever been observed on 86-32, but it isn't a target-specific bug. It's probably not specific to G1 either.
As this is a fatal crash on 32-bit x86, I am requesting fixes for JDK 8 and JDK 11. The approved upstream patch http://cr.openjdk.java.net/~aph/8225716-2/ applies as is to JDK 11. JDK 8 requires some changes because Atomic doesn't support bytes: http://cr.openjdk.java.net/~aph/8225716-jdk8u/ . This is OK because volatile should be sufficient to ensure correctness.

The same basic loop also exists BlockOffsetArrayNonContigSpace::block_start_unsafe (http://hg.openjdk.java.net/jdk/jdk13/file/c3b354fdbaa4/src/hotspot/share/gc/shared/blockOffsetTable.cpp#l533), so the other parallel collectors might also be affected.

RFR: https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-June/026193.html