JDK-8233027 : OopMapSet::all_do does oms.next() twice during iteration
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11.0.9-oracle,14
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2019-10-25
  • Updated: 2021-02-03
  • Resolved: 2019-10-25
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
11.0.9-oracleFixed 13.0.6Fixed 14 b21Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Description
It seems to be introduced by JDK-8232083. New code does oms.next() twice:

    for (OopMapStream oms(map); !oms.is_done(); oms.next()) { // <--- here
      OopMapValue omv = oms.current();
      if (omv.type() != OopMapValue::derived_oop_value) {
        continue;
      }
      ...
      if (base_loc != NULL && *base_loc != NULL && !CompressedOops::is_base(*base_loc)) {
        derived_oop_fn(base_loc, derived_loc);
      }
      oms.next(); // <--- then here
    }

We are seeing some weird, random, intermittent test failures with Shenandoah in jdk/jdk recently, this might explain it.
Comments
Fix request (13u) -- will label after testing completed. I would like to backport the fix to jdk13u for parity with jdk11u. The original patch applied cleanly.
25-01-2021

Fix request (11u) -- will label after testing completed. I would like to downport this for parity with 11.0.9-oracle. Applies clean.
28-05-2020

URL: https://hg.openjdk.java.net/jdk/jdk/rev/d3382812b788 User: kvn Date: 2019-10-25 20:12:02 +0000
25-10-2019

I will run tier2 and 3 too.
25-10-2019

I submitted testing for this fix to make sure it solves issues we see.
25-10-2019

I just posted it.
25-10-2019

Please do RFR, I can review it then and tell it fixes the actual failures :)
25-10-2019

Yes that's my conclusion too. If you post that I'll review it, or would you rather I do so?
25-10-2019

Thanks. The failures that look like heap corruption seem to be reproduced across multiple machines when running hotspot_gc_shenandoah; on random tests, though, and they seem to crash in C2-generated OSR-compiled code. This patch seems to shoo the failures away: https://cr.openjdk.java.net/~shade/8233027/webrev.01/
25-10-2019

Yes that looks wrong. I'll fix it.
25-10-2019

I think Tom had rewritten that code in JDK-8232083. Tom, can you please take a look?
25-10-2019