[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