du369 du369 - 18 days ago 5
Java Question

Java final keyword semantics with respect to cache

What is the behavior of Java final keyword with respect of caches?

quote from:jsr133-faq


The values for an object's final fields are set in its constructor.
Assuming the object is constructed "correctly", once an object is
constructed, the values assigned to the final fields in the
constructor will be visible to all other threads without
synchronization. In addition, the visible values for any other object
or array referenced by those final fields will be at least as
up-to-date as the final fields.


I don't understand what it refers to when it says
as up-to-date as the final fields
.:


In addition, the visible values for any other object or array
referenced by those final fields will be at least as up-to-date as the
final fields.


My guess is, for example:

public class CC{
private final Mutable mutable; //final field
private Other other; //non-final field

public CC(Mutable m, Other o){
mutable=m;
other=o;
}
}


When the constructor CC returns, besides the pointer value of
mutable
, all values on the object graph rooted at
m
, if exist in the local processor cache, will be flushed to main memory. And at the same time, mark the corresponding cache lines of other processors' local caches as Invalid.

Is that the case? What does it look like in assembly? How do they actually implement it?

Answer

Is that the case?

The actual guarantee is that any thread that can see an instance of CC created using that constructor is guaranteed to see the mutable reference and also the state of the Mutable object's fields as of the time that the constructor completed or later.

It does not guarantee that the state of all values in the closure of the Mutable instance will be visible.

Note that the behavior is specified in terms what one thread is guaranteed to see, not in terms of cache flushing / invalidation. The latter is a way of implementing the behavior that the specification requires. There may be other ways.

What does it look like in assembly?

That will be version / platform / etc specific. There is a way to get the JIT compiler to dump out the compiled code, if you want to investigate what the native code looks like for your hardware.

How do they actually implement it?

See above.