final vs. volatile instance fields

[Aleksey Shipilev]

Hi Peter,

You should really consider reading JSR 133 Cookbook:
http://g.oswego.edu/dl/jmm/cookbook.html

I think you will need to move this discussion on concurrency-interest@ if you want the discussion on broader cross-hardware cross-implementation scope.

On 26.12.2012, at 15:58, Peter Levart <peter.levart at gmail.com> wrote:

> Are there any performance differences in reading and writing of volatile vs. final instance fields? I can see that reflection is doing the same for both types (via UnsafeQualifiedFieldAccessorImpl subtypes) and is reading/writing the fields using Unsafe.getXxxVolatile/putXxxVolatile. So what does the JIT compiled code do?

The short answer is that volatile read generally entails more than just a read, it should also conform to JMM, and as such entail barriers, which might exhibit performance costs due to breaking the pipelining, register allocation, ant other fruitful optimizations. While the barriers might be no-oped on some hardware (x86 included), the compiler effects are still in place.

Writing final fields is troublesome to reason, and I fully expect JVMs to bailout to volatile-like semantics to preserve (weaker) final fields invariants.

> a) Are there any differences between writing to those two types of fields? The Java spec. mandates writing to final fields exactly once in the constructors and Java Memory Model says that they are "frozen" at the end of constructor. What does "freeze" actually translate to in the compiled code?

Final fields entail the barrier at the end of constructor, and then piggyback heavily on data-dependency (absence) of reordering. Cookbook explains this well enough. And writing volatile fields can incur prohibitive costs due to JMM effects needing to be enforced.

> b) I can understand that the JIT compiler can generate code that caches the value of final field say in a register, but initially the code has to load the value from a final field and the question is whether this initial load is any different from a volatile read?

Uhm... Depends on "difference". Yes, reading the final field requires reading the object reference first, and so we can piggyback for almost all of the commodity hardware to not to reorder dependent reads. On hypothetical hardware (Alpha, die already!) you have no such guarantee and reading the final fields will incur barriers similar to volatile read.

-Aleksey.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121226/c546132c/attachment.html