[14] RFR (XS): 8235305: Corrupted oops embedded in nmethods due to parallel modification during optional evacuation

Thomas Schatzl thomas.schatzl at oracle.com
Thu Jan 16 13:20:15 UTC 2020

Hi all,

   can I get reviews for this change that fixes a bug in the abortable 
mixed gc algorithm where G1 might corrupt oops embedded in nmethods due 
to parallel modification during an optional evacuation phase?

G1 currently collects embedded oops in nmethods twice: once in the 
optional roots list, and once as nmethods in the strong code roots list 
for a particular region.

Now it can happen that this oop embedded in in the code stream is 
unaligned, so if that oop is modified during relocation word tearing may 
occur, causing follow-up crashes.

The fix is to not collect oops from nmethods in the optional code root 
list as the strong code root list for a particular region already always 
contains it anyway.

Thanks go to stefank, eriko and sjohanss for helping with analyzing, 
testing and the discussion around it.

multiple runs of hs-tier1-5, multiple runs of the crashing application 
(24h kitchensink) with and without a VM modification and also with some 
G1 settings that caused crashes within 1-2 hours that reproduced the 
issue within 5 minutes.
Currently starting perf test runs with and without this change: however 
since this change strictly reduces the work done at all times I am not 
expecting any regressions (and hence I am asking for review in advance).


More information about the hotspot-gc-dev mailing list