<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 12/26/2012 01:31 PM, Aleksey
Shipilev wrote:<br>
</div>
<blockquote
cite="mid:4EBB542F-1E73-47F0-86E0-34C0929A8F33@oracle.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div>Hi Peter,</div>
<div><br>
</div>
<div>You should really consider reading JSR 133 Cookbook:</div>
<div><a moz-do-not-send="true"
href="http://g.oswego.edu/dl/jmm/cookbook.html">http://g.oswego.edu/dl/jmm/cookbook.html</a></div>
<div><br>
</div>
</blockquote>
Sergey, Aleksey, thank you very much for the pointer to the
Coockbook. This is a valuable resource.<br>
<br>
All the best,<br>
<br>
Peter<br>
<br>
<blockquote
cite="mid:4EBB542F-1E73-47F0-86E0-34C0929A8F33@oracle.com"
type="cite">
<div>I think you will need to move this discussion on
concurrency-interest@ if you want the discussion on broader
cross-hardware cross-implementation scope.</div>
<div><br>
On 26.12.2012, at 15:58, Peter Levart <<a
moz-do-not-send="true" href="mailto:peter.levart@gmail.com">peter.levart@gmail.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div><span>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?</span><br>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Writing final fields is troublesome to reason, and I fully
expect JVMs to bailout to volatile-like semantics to preserve
(weaker) final fields invariants.</div>
<br>
<blockquote type="cite">
<div><span>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?</span><br>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<br>
<blockquote type="cite">
<div><span>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?</span><br>
</div>
</blockquote>
<div><br>
</div>
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.
<div><br>
</div>
<div>-Aleksey.</div>
</blockquote>
<br>
</body>
</html>