-
Enhancement
-
Resolution: Duplicate
-
P4
-
9, 10
-
arm
This is again surfaced during the JMM9 overhaul effort.
In short, HotSpot emits StoreStore barrier after writing out the object headers (C1 does it explicitly, and C2 by the means of AllocateNode). If a write to final field is present in the initializer, then we also emit MemBarRelease, which is LoadStore+StoreStore. It seems redundant to have both barriers, when we can subsume the object header barrier into the final LoadStore+StoreStore.
This is the job for high-level opimizer, but the effect is mostly visible on weakly-ordered architectures, where both StoreStore and LoadStore+StoreStore materialize.
In short, HotSpot emits StoreStore barrier after writing out the object headers (C1 does it explicitly, and C2 by the means of AllocateNode). If a write to final field is present in the initializer, then we also emit MemBarRelease, which is LoadStore+StoreStore. It seems redundant to have both barriers, when we can subsume the object header barrier into the final LoadStore+StoreStore.
This is the job for high-level opimizer, but the effect is mostly visible on weakly-ordered architectures, where both StoreStore and LoadStore+StoreStore materialize.
- duplicates
-
JDK-8300148 Consider using a StoreStore barrier instead of Release barrier on ctor exit
- Resolved
- relates to
-
JDK-8032218 Emit single post-constructor barrier for chain of superclass constructors
- Open