<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <pre><span class="changed">I notice that there is a variable that was already there (not one you added this time)
also mis-spelled : isFPMethodOverriden

I'd prefer that be fixed in this push but I don't need to see an updated webrev for that.

Comments about threading noted.

+1

-phil.
</span></pre>
    <br>
    <br>
    <div class="moz-cite-prefix">On 12/20/2016 12:52 PM, Alexandr
      Scherbatiy wrote:<br>
    </div>
    <blockquote
      cite="mid:0c4c9c82-094f-1b0e-82d0-cd2ab7e3a8f1@oracle.com"
      type="cite">
      <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
      On 12/16/2016 2:36 AM, Phil Race wrote:<br>
      <blockquote
        cite="mid:5e61c9a3-becc-9db7-4ec6-95dfba12ff1a@oracle.com"
        type="cite">
        <meta content="text/html; charset=utf-8"
          http-equiv="Content-Type">
        I just noticed that you spell the new methods with a single d
        :eg :  <span class="changed">getFPMethodOverriden<br>
          <br>
          Like the variables that were there before it should be  </span><span
          class="changed">getFPMethodOverridden<br>
          and </span><span class="changed">checkFPMethodOverridden<br>
        </span></blockquote>
      Â Â  Here is the updated fix where the typo is updated:<br>
      Â Â Â  <a moz-do-not-send="true" class="moz-txt-link-freetext"
        href="http://cr.openjdk.java.net/%7Ealexsch/8169922/webrev.02">http://cr.openjdk.java.net/~alexsch/8169922/webrev.02</a><br>
      <br>
      <blockquote
        cite="mid:5e61c9a3-becc-9db7-4ec6-95dfba12ff1a@oracle.com"
        type="cite"><span class="changed"> <br>
          Also, although rather unlikely to be a problem in practice,
          since there<br>
          is nothing in the swing rules to prevent constructing a Swing
          component on<br>
          a random thread, before adding it to the hierarchy, and the
          shared Map is populated<br>
          at construction time, it seems like we need a
          ConcurrentHashMap ..<br>
        </span></blockquote>
      Â  It seems that it could be possible that a constructor can
      schedule to run some actions calling SwingUtilities.invokeLater().<br>
      Â  In this case both threads (the thread where a Swing component is
      constructor and EDT) can simultaneously start the object fields
      updating.<br>
      Â  There is  still no guarantee that all works as expected if a
      Swing component is constructed in non-EDT.<br>
      <br>
      Â  Thanks,<br>
      Â  Alexandr. <br>
      Â <br>
      <blockquote
        cite="mid:5e61c9a3-becc-9db7-4ec6-95dfba12ff1a@oracle.com"
        type="cite"><span class="changed"> <br>
          -phil.<br>
          <br>
        </span>
        <div class="moz-cite-prefix">On 12/15/2016 09:06 AM, Alexandr
          Scherbatiy wrote:<br>
        </div>
        <blockquote
          cite="mid:c8bc1b1c-2579-342c-4fb7-b31bf5221765@oracle.com"
          type="cite"> <br>
          Hello, <br>
          <br>
          Could you review the updated fix: <br>
          Â  <a moz-do-not-send="true" class="moz-txt-link-freetext"
            href="http://cr.openjdk.java.net/%7Ealexsch/8169922/webrev.01">http://cr.openjdk.java.net/~alexsch/8169922/webrev.01</a>
          <br>
          <br>
          - the HashMap is stored in SoftRefence <br>
          - the typo in getMethodArguments() is fixed <br>
          - classes FPMethodItem and FPMethodArgs are defined in the
          PlainView class. <br>
          <br>
          Thanks, <br>
          Alexandr. <br>
          <br>
          On 12/14/2016 8:30 PM, Sergey Bylokhov wrote: <br>
          <blockquote type="cite">Hi, Alexander. <br>
            Should not the storage be based on soft references? In the
            current solution we will store the references to the checked
            classes forever in the static map. <br>
            <br>
            <blockquote type="cite">13 Ð´ÐµÐº. 2016 Ð³., Ð² 18:41, Alexandr
              Scherbatiy <a moz-do-not-send="true"
                class="moz-txt-link-rfc2396E"
                href="mailto:alexandr.scherbatiy@oracle.com"><alexandr.scherbatiy@oracle.com></a>
              Ð½Ð°Ð¿Ð¸ÑÐ°Ð»(а): <br>
              <br>
              <br>
              Hello, <br>
              <br>
              Could you review the fix: <br>
              Â  bug: <a moz-do-not-send="true"
                class="moz-txt-link-freetext"
                href="https://bugs.openjdk.java.net/browse/JDK-8169922">https://bugs.openjdk.java.net/browse/JDK-8169922</a>
              <br>
              Â  webrev: <a moz-do-not-send="true"
                class="moz-txt-link-freetext"
                href="http://cr.openjdk.java.net/%7Ealexsch/8169922/webrev.00">http://cr.openjdk.java.net/~alexsch/8169922/webrev.00</a>
              <br>
              <br>
              Â  The fix JDK-8156217 checks presence of the overridden
              methods with floating point arguments. <br>
              Â  The proposed fix caches results of found overridden
              methods with floating point arguments. <br>
              <br>
              Â  I run the SwingSet2 with the custom test which
              intensively creates JTextField, JPasswordField, JTextArea,
              and JEditorPane. <br>
              <br>
              Â  The results of the test running with the following JDK
              are: <br>
              Â  1. Methods with int arguments are always called without
              the methods overridden check: 45822 // before the fix
              JDK-8156217 <br>
              Â  2. Methods with floating point arguments are always
              called without the methods overridden check: 46175 <br>
              Â Â Â  performance decreasing: 100 * (46175 - 45822) / 45822
              = 0.77% <br>
              Â  3. Methods with floating point arguments are always
              called with the methods overridden check: 48836 // fix
              JDK-8156217 <br>
              Â Â Â  performance decreasing: 100 * (48836 - 45822) / 45822
              = 6.58% <br>
              Â  4. Methods with floating point arguments are always
              called and the methods overridden checks are cached: 46592
              // current fix <br>
              Â Â Â  performance decreasing: 100 * (46592 - 45822) / 45822
              = 1.68% <br>
              <br>
              Thanks, <br>
              Alexandr. <br>
              <br>
            </blockquote>
          </blockquote>
          <br>
        </blockquote>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>