<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body style="background-color: rgb(255, 255, 255); color: rgb(0, 0,
    0);" text="#000000" bgcolor="#FFFFFF">
    Hi David,<br>
    <br>
    I was thinking about the fact that java.lang.invoke code is leaking
    into java.lang.Class. Perhaps, If you don't mind rewriting the code,
    a better code structure would be, if j.l.Class changes only
    consisted of adding a simple:<br>
    <br>
    + // A reference to canonicalizing cache of
    java.lang.invoke.MemberName(s) <br>
    + // for members declared by class represented by this Class object<br>
    + private transient volatile Object memberNameData;<br>
    <br>
    ...and nothing else. All the logic could live in MemberName itself
    (together with Unsafe machinery for accessing/cas-ing
    Class.memberNameData).<br>
    <br>
    Now to an idea about implementation. Since VM code is not doing any
    binary-search and only linearly scans the array when it has to
    update MemberNames, the code could be changed to scan a linked-list
    of MemberName(s) instead. You could add a field to MemberName:<br>
    <br>
    class MemberName {<br>
    ...<br>
        // next MemberName in chain of interned MemberNames for
    particular declaring class<br>
        private MemberName next;<br>
    <br>
    <br>
    Have a volatile field in MemberNameData (or ClassData - whatever you
    call it):<br>
    <br>
    class MemberNameData {<br>
    ...<br>
        // a chain of interned MemberName(s) for particular declaring
    class<br>
        // accessed by VM when it has to modify them in-place<br>
        private volatile MemberName memberNames;<br>
    <br>
        MemberName add(<span class="new">Class<?> klass, int
      index, MemberName mn, int redefined_count) {<br>
              mn.next = </span><span class="new">memberNames;<br>
              </span><span class="new"><span class="new">memberNames =
        mn;<br>
                if (jla.getClassRedefinedCount(klass) == </span></span><span
      class="new"><span class="new"><span class="new">redefined_count) {
          // no changes to class<br>
                      ...<br>
                      ... code to update array of sorted MemberName(s)
          with new 'mn'<br>
                      ...<br>
                      return mn;<br>
                  }<br>
                  // lost race, undo insertion<br>
                  </span></span></span><span class="new"><span
        class="new"><span class="new"><span class="new">memberNames =
            mn.next;<br>
                    return null;<br>
          </span></span></span>    }<br>
    </span><br>
    <br>
    This way all the worries about ordering of writes into array and/or
    size are gone. The array is still used to quickly search for an
    element, but VM only scans the linked-list.<br>
    <br>
    What do you think of this?<br>
    <br>
    Regards, Peter<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 11/03/2014 05:36 PM, David Chase
      wrote:<br>
    </div>
    <blockquote
      cite="mid:F5B0B719-8B7B-4FDF-96E3-4058E223E74B@oracle.com"
      type="cite"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900;  padding: 0px 15px; margin: 2px 0px;"><![endif]-->
      <pre wrap=""></pre>
      <blockquote type="cite"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900;  padding: 0px 15px; margin: 2px 0px;"><![endif]-->
        <blockquote type="cite"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900;  padding: 0px 15px; margin: 2px 0px;"><![endif]-->
          <pre wrap="">My main concern is that the compiler is inhibited from any peculiar code motion; I assume that taking a safe point has a bit of barrier built into it anyway, especially given that the worry case is safepoint + JVMTI.

Given the worry, what’s the best way to spell “barrier” here?
I could synchronize on classData (it would be a recursive lock in the current version of the code)
  synchronized (this) { size++; }
or I could synchronize on elementData (no longer used for a lock elsewhere, so always uncontended)
  synchronized (elementData) { size++; }
or is there some Unsafe thing that would be better?
</pre>
          <!--[if !IE]></DIV><![endif]--></blockquote>
        <pre wrap=""></pre>
        <!--[if !IE]></DIV><![endif]--></blockquote>
      <pre wrap=""></pre>
      <blockquote type="cite"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900;  padding: 0px 15px; margin: 2px 0px;"><![endif]-->
        <pre wrap="">You're worried that writes moving array elements up for one slot would bubble up before write of size = size+1, right? If that happens, VM could skip an existing (last) element and not update it.
</pre>
        <!--[if !IE]></DIV><![endif]--></blockquote>
      <pre wrap="">exactly, with the restriction that it would be compiler-induced bubbling, not architectural.
Which is both better, and worse — I don’t have to worry about crazy hardware, but the rules
of java/jvm "memory model" are not as thoroughly defined as those for java itself.

I added a method to Atomic (.storeFence() ).  New webrev to come after I rebuild and retest.

Thanks much,

David

</pre>
      <blockquote type="cite"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900;  padding: 0px 15px; margin: 2px 0px;"><![endif]-->
        <pre wrap="">It seems that Unsafe.storeFence() between size++ and moving of elements could do, as the javadoc for it says:

   /**
    * Ensures lack of reordering of stores before the fence
    * with loads or stores after the fence.
    * @since 1.8
    */
   public native void storeFence();
</pre>
        <!--[if !IE]></DIV><![endif]--></blockquote>
      <pre wrap=""></pre>
      <!--[if !IE]></DIV><![endif]--></blockquote>
    <br>
  </body>
</html>