JDK-8145948 : C2: Initializing volatile fields to default values should be optimized
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2015-12-21
  • Updated: 2024-06-14
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-6736490 - Remove unnecessary explicit initialization of volatile variables
Description
This is a compiler-side follow-up for JDK-6736490. 

class A {
    volatile int x;
}

class B {
    volatile int x = 0;
}

These two classes appear different, but they have the same semantics in both single-threaded and multi-threaded cases:
 http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014767.html

However, class B would be much slower to initialize, because the volatile field init would be present in constructor generated code. We may want to elide that volatile store to improve performance for all existing code.

Benchmark, performance data, and generated code:
 http://cr.openjdk.java.net/~shade/8145948/InitStores.java
 http://cr.openjdk.java.net/~shade/8145948/benchmarks.jar
Comments
Draft PR: https://github.com/openjdk/jdk/pull/19721
14-06-2024
I'm not sure if we would like to do this optimization in C1 as well (not only in C2).
14-02-2017