JDK-8225809 : Investigate JDK-8225716 impact on other generational collectors
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 13
  • Priority: P2
  • Status: Resolved
  • Resolution: Not an Issue
  • Submitted: 2019-06-14
  • Updated: 2019-06-19
  • Resolved: 2019-06-18
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 13
13Resolved
Related Reports
Relates :  
JDK-8225716 - G1 GC: Undefined behaviour in G1BlockOffsetTablePart::block_at_or_preceding
Description
Other collectors may have a similar race problem as that discovered in G1's BOT - see JDK-8225716.  Investigate and fix if needed.
Comments
CMS old gen collector is single-threaded, so no issue. During scanning cards of the mod-union table (and accessing the BOT), CMS takes the global freelist-lock that is also taken when doing direct old-gen allocations.
19-06-2019
And Serial GC is trivially safe.
18-06-2019
Peter Kessler's statement looks correct, no parallel update of the BOT is possible as Parallel splits work into regions that are the claimed exclusively for processing. Partial objects crossing "regions" are handled in a special "Deferred Updates" single threaded phase. Closing as Not an Issue.
18-06-2019
PSMarkSweep is single-threaded too.
18-06-2019
Peter Kessler (via email) suggests other collectors don't have a similar problem, because their BOT updates are not racing with accesses. On Jun 14, 2019, at 3:54 PM, Peter B. Kessler wrote: ParallelGC only updates the block offset table when copying objects. Copying is to a destination claimed by a GC worker, so no other GC thread is reading that part of the BOT while it is being written. CMS does not move objects in the old generation, so the BOT for an object does not change once the object is in place. I don't know what CMS does if it has to defragment the heap by running a compacting collection. If I recall correctly: it has been a while since I looked at any of that code. It would be a shame to make access to the BOT volatile/atomic for the collectors that do not need that overhead. Your memory system will thank you for your attention to this detail.
14-06-2019