<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 &lt;<a
          moz-do-not-send="true" href="mailto:peter.levart@gmail.com">peter.levart@gmail.com</a>&gt;
        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>