Skip to content

Commit b0e7271

Browse files
committed
8230434: [C1, C2] Release barrier for volatile field stores in constructors implemented inconsistently
Reviewed-by: shade, lucy
1 parent f7d0ece commit b0e7271

File tree

2 files changed

+18
-14
lines changed

2 files changed

+18
-14
lines changed

src/hotspot/share/c1/c1_GraphBuilder.cpp

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1467,11 +1467,12 @@ void GraphBuilder::method_return(Value x, bool ignore_return) {
14671467
call_register_finalizer();
14681468
}
14691469

1470+
// The conditions for a memory barrier are described in Parse::do_exits().
14701471
bool need_mem_bar = false;
14711472
if (method()->name() == ciSymbol::object_initializer_name() &&
1472-
(scope()->wrote_final() || (AlwaysSafeConstructors && scope()->wrote_fields())
1473-
|| (support_IRIW_for_not_multiple_copy_atomic_cpu && scope()->wrote_volatile())
1474-
)){
1473+
(scope()->wrote_final() ||
1474+
(AlwaysSafeConstructors && scope()->wrote_fields()) ||
1475+
(support_IRIW_for_not_multiple_copy_atomic_cpu && scope()->wrote_volatile()))) {
14751476
need_mem_bar = true;
14761477
}
14771478

src/hotspot/share/opto/parse1.cpp

Lines changed: 14 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -979,25 +979,28 @@ void Parse::do_exits() {
979979
// Rather than put a barrier on only those writes which are required
980980
// to complete, we force all writes to complete.
981981
//
982-
// 2. On PPC64, also add MemBarRelease for constructors which write
983-
// volatile fields. As support_IRIW_for_not_multiple_copy_atomic_cpu
984-
// is set on PPC64, no sync instruction is issued after volatile
985-
// stores. We want to guarantee the same behavior as on platforms
986-
// with total store order, although this is not required by the Java
987-
// memory model. So as with finals, we add a barrier here.
988-
//
989-
// 3. Experimental VM option is used to force the barrier if any field
982+
// 2. Experimental VM option is used to force the barrier if any field
990983
// was written out in the constructor.
991984
//
985+
// 3. On processors which are not CPU_MULTI_COPY_ATOMIC (e.g. PPC64),
986+
// support_IRIW_for_not_multiple_copy_atomic_cpu selects that
987+
// MemBarVolatile is used before volatile load instead of after volatile
988+
// store, so there's no barrier after the store.
989+
// We want to guarantee the same behavior as on platforms with total store
990+
// order, although this is not required by the Java memory model.
991+
// In this case, we want to enforce visibility of volatile field
992+
// initializations which are performed in constructors.
993+
// So as with finals, we add a barrier here.
994+
//
992995
// "All bets are off" unless the first publication occurs after a
993996
// normal return from the constructor. We do not attempt to detect
994997
// such unusual early publications. But no barrier is needed on
995998
// exceptional returns, since they cannot publish normally.
996999
//
9971000
if (method()->is_initializer() &&
998-
(wrote_final() ||
999-
PPC64_ONLY(wrote_volatile() ||)
1000-
(AlwaysSafeConstructors && wrote_fields()))) {
1001+
(wrote_final() ||
1002+
(AlwaysSafeConstructors && wrote_fields()) ||
1003+
(support_IRIW_for_not_multiple_copy_atomic_cpu && wrote_volatile()))) {
10011004
_exits.insert_mem_bar(Op_MemBarRelease, alloc_with_final());
10021005

10031006
// If Memory barrier is created for final fields write

0 commit comments

Comments
 (0)