JDK-8173195 : [BACKOUT] 8087341: C2 doesn't optimize redundant memory operations with G1
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2017-01-23
  • Updated: 2020-09-01
  • Resolved: 2017-01-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 10 JDK 9
10Fixed 9 b156Fixed
Related Reports
Blocks :  
Relates :  
Relates :  
Relates :  
JDK-8087341 causes an anti-dependency on the volatile membar that results in a crash in the register allocator due to invalid instruction scheduling (see JDK-8172850). Since we are very late in the JDK 9 release cycle, we should back out the change and redo the enhancement in JDK 10.
verified by PIT testing

[~jwilhelm], this is an integration blocker because it will fix JDK-8172850 which is an integration blocker.

Tobias, okay.

What makes this an integration blocker? If it is caused by JDK-8087341 that was pushed in March 2016 the problem is already in jdk9/dev and this is per definition not a blocker.

I think we could but from my understanding most the aarch64 changes are required as well. Roland will re-do them with JDK-8173196.

Can we revert only C2 code and not aarch64?