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

Thomas Schatzl thomas.schatzl at oracle.com
Fri Jan 17 08:55:52 UTC 2020


Hi,

On 16.01.20 14:20, Thomas Schatzl wrote:
> 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.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8235305
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8235305/webrev/
> Testing:
> 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).
> 

   no perf differences as expected.

Another hs-tier1-5 completed, and hs-tier6-8 almost done without new issues.

Thanks,
   Thomas



More information about the hotspot-gc-dev mailing list