<p>Doing dynamic re-layout and contention adjustment seems nice in thought but how practical is that? I can't see how that would be cheap enough where it's worth the cost. What if the app goes through phases of contention? Initially high but then no sharing - would the bloated object layout be worth it at that point? Seems like this is a place where explicit developer instructions is better than heuristics with potentially expensive consequences.</p>

<p>Sent from my phone</p>
<div class="gmail_quote">On Jan 17, 2012 12:44 PM, "Nathan Reynolds" <<a href="mailto:nathan.reynolds@oracle.com">nathan.reynolds@oracle.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    Assuming that the JVM can optimize for true and false sharing (and
    that is a big assumption at the moment), then you can focus your
    time on writing useful code.  Furthermore, optimizing for true and
    false sharing will never be able to fix actual data contention.  We
    still need clever ways of sharing data without bottlenecks.<br>
    <br>
    <div><a href="http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds" target="_blank">Nathan
        Reynolds</a> | Consulting Member of Technical Staff |
      <a href="tel:602.333.9091" value="+16023339091" target="_blank">602.333.9091</a><br>
      <font color="red">Oracle</font> <a href="http://psr.us.oracle.com/" target="_blank">PSR Engineering</a> | Server
      Technology<br>
    </div>
    <br>
    On 1/17/2012 10:29 AM, Ruslan Cheremin wrote:
    <blockquote type="cite">
      <pre>You made my day. Few months ago I was dreaming (in my blog) about
complexity of false sharing prevention with padding. And come to two
options, one better another. First one was @PreventFalseSharing
annotation, next was atomatically contention detection and relocation
of contended objects by JIT. Readers of my blog soon pointed me to
@Contended annotation. And now you telling the second -- the best --
option is also being explored!

Just want to ask -- if all good things will be done by JIT -- what I
will be paid for?

2012/1/17 Nathan Reynolds <a href="mailto:nathan.reynolds@oracle.com" target="_blank"><nathan.reynolds@oracle.com></a>:
</pre>
      <blockquote type="cite">
        <pre>It would be nice if the processor could effectively tell the JVM that false
sharing is happening.  It would be nice if the JVM could respond by moving
objects within the heap or fields with the class to avoid false sharing.
Thus, we don't have to pad or worry about placing @Contended or other
attributes into the class.

Intel was looking into to optimizing for true and false sharing.  They had a
prototype that worked but required restarting the JVM.  Oracle was looking
into dynamically relayout fields in objects.  I haven't heard anything from
either group for a while...  I haven't asked either.  *IF* a solution
becomes available, then it will be a while.  This is a very difficult thing
to do.

Nathan Reynolds | Consulting Member of Technical Staff | <a href="tel:602.333.9091" value="+16023339091" target="_blank">602.333.9091</a>
Oracle PSR Engineering | Server Technology

On 1/17/2012 9:35 AM, Vitaly Davidovich wrote:

OK I see what you mean now.  I imagine @Contended will be used with fields
rather than classes so when the JVM lays out an instance of the class I
assume it will do two-sided padding on the contended field if required or if
natural layout is such that prior fields already fill up a cache line then
only one sided is needed.

Sent from my phone

On Jan 17, 2012 11:27 AM, "Ruslan Cheremin" <a href="mailto:cheremin@gmail.com" target="_blank"><cheremin@gmail.com></a> wrote:
</pre>
        <blockquote type="cite">
          <pre>
2012/1/17 Vitaly Davidovich <a href="mailto:vitalyd@gmail.com" target="_blank"><vitalyd@gmail.com></a>:
</pre>
          <blockquote type="cite">
            <pre>I think it's semantics - if you sometimes allocate with 64/128 byte
alignment then if your object is smaller than 64/128 the rest of the
space
is effectively padding.
</pre>
          </blockquote>
          <pre>
Agree. But in case of alignment you lose sense of "one-side" or "two
side" padding -- you do not need "two side padding", you just make
sure object align on cache line boundary.

Actually I was asked is my understanding of how @Contended supposed to
be implemented is right?

</pre>
          <blockquote type="cite">
            <pre>Or are you saying you want an @Alignment annotation
instead so it's more general? What other uses of custom alignment do you
envision? Java is too high-level  and the underlying hardware/platform
too
abstracted away for a general purpose custom alignment hint, IMHO.
</pre>
          </blockquote>
          <pre>
No, I do not want such ugly thing to happen with java! It's enough C
for such things...


</pre>
          <blockquote type="cite">
            <pre>Sent from my phone

On Jan 17, 2012 10:56 AM, "Ruslan Cheremin" <a href="mailto:cheremin@gmail.com" target="_blank"><cheremin@gmail.com></a> wrote:
</pre>
            <blockquote type="cite">
              <pre>
</pre>
              <blockquote type="cite">
                <pre>Yes. As a practical matter though, until an @Contended attribute
or something like it is supported across JVMS (see list archives for
discussion), you cannot arrange reliable two-sided padding
for objects with mixed field types (ints, longs, refs that may be
either 32 or 64 bits, etc), so one-sided is the best you can do.
</pre>
              </blockquote>
              <pre>
By the way -- I was not thinking about @Contended as "make padding for
me". It seems for me like padding is only dirty hack, since nothing
better available. If I would control memory allocation (like JVM does)
I just can allocate @Contended objects on 64 (128... etc) bytes
boundary. I do not have to "pad" them -- nor both, nor one side. And I
suppose @Contended implementation to do exactly this -- "use special
allocator for objects of that type, which allocate them on cache line
boundary"

Am I wrong here?


</pre>
              <blockquote type="cite">
                <pre>
-Doug
_______________________________________________
Concurrency-interest mailing list
<a href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.oswego.edu</a>
<a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a>
</pre>
              </blockquote>
              <pre>_______________________________________________
Concurrency-interest mailing list
<a href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.oswego.edu</a>
<a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a>
</pre>
            </blockquote>
          </blockquote>
        </blockquote>
        <pre>


_______________________________________________
Concurrency-interest mailing list
<a href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.oswego.edu</a>
<a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a>
</pre>
      </blockquote>
    </blockquote>
  </div>

</blockquote></div>