Final Fields with Shenandoah

[Aleksey Shipilev]

On 12/17/19 1:14 PM, Eugeniu Rabii wrote:
> I am trying  to run this example 
> http://hg.openjdk.java.net/code-tools/jcstress/file/3dcb38e98aa6/jcstress-samples/src/main/java/org/openjdk/jcstress/samples/JMMSample_06_Finals.java
I firmly believe you misunderstood that example.

The test verifies that final fields allow data to survive the races: the field stores that happen in
constructor are visible to every thread that sees the object "later". Shenandoah (or any other) GC
cannot break this, it is a hard requirement for Java Memory Model.

What you seem to be confusing this behavior with is: when you *modify* (e.g. by Reflection) the
final field after the object was published, JMM allows seeing old value, even if you have obvious
side effects, or even the hard synchronization. JLS has a good example of this, see "Example
17.5.3-1. Aggressive Optimization of final Fields".

Shenandoah GC used to capitalize on this by allowing reads of final fields to bypass the read
barriers, and thus read the "old" copy of the object, which might contain the old value for the
final field. Note this is allowed by JMM, and this is not what the test in question verifies.

(Un)fortunately, you would not be able to show this with current Shenandoah, because it employs
stronger invariant: "old" object is never accessible by application.

-- 
Thanks,
-Aleksey