<html>
  <head>
    <meta content="text/html; charset=windows-1251"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <tt>Thanks for review, Jon!<br>
      -- Dima<br>
      <br>
    </tt>
    <div class="moz-cite-prefix">On 27.08.2014 20:06, Jon Masamitsu
      wrote:<br>
    </div>
    <blockquote cite="mid:53FE01EF.1010903@oracle.com" type="cite">
      <meta content="text/html; charset=windows-1251"
        http-equiv="Content-Type">
      <br>
      <div class="moz-cite-prefix">On 8/27/2014 8:23 AM, Dmitry
        Fazunenko wrote:<br>
      </div>
      <blockquote cite="mid:53FDF7DF.7030109@oracle.com" type="cite">
        <meta content="text/html; charset=windows-1251"
          http-equiv="Content-Type">
        Jon,<br>
        <br>
        My patch fixes the original problem: tests will fail instead,
        not hang up.<br>
        Printing extra debug info is a different story, and should
        require a separate RFE.<br>
      </blockquote>
      <br>
      Agreed.<br>
      <br>
      <blockquote cite="mid:53FDF7DF.7030109@oracle.com" type="cite"> To
        print char[] addresses WhiteBoxAPI needs to be used, without it
        only following data could be printed out:<br>
        <br>
        String   'DeduplicationTestString:7:XXXXXXXXXXXXXXXXXXXXXXXX'
        has not deduplicated<br>
            char1[]: [C@7ea987ac<br>
            char2[]: [C@12a3a380<br>
        <br>
        but I think this is valueless.<br>
      </blockquote>
      <br>
      I think there is some value is seeing that the two char arrays<br>
      are different.   Maybe not enough though.  Your call on this.<br>
      <br>
      <blockquote cite="mid:53FDF7DF.7030109@oracle.com" type="cite"> <br>
        May be we can fix <br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
          href="http://cr.openjdk.java.net/%7Edfazunen/8050464/webrev.01/">http://cr.openjdk.java.net/~dfazunen/8050464/webrev.01/</a><br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
          href="https://bugs.openjdk.java.net/browse/JDK-8050464">https://bugs.openjdk.java.net/browse/JDK-8050464</a><br>
      </blockquote>
      <br>
      Changes look good.  If we see failures of the test, we can<br>
      look at why it failed and maybe come up with some additional<br>
      output.<br>
      <br>
      Reviewed.<br>
      <br>
      Jon<br>
      <br>
      <br>
      <br>
      <blockquote cite="mid:53FDF7DF.7030109@oracle.com" type="cite"> <br>
        and file an RFE of further improvement?<br>
        <br>
        Thanks,<br>
        Dima<br>
        <br>
        <br>
        <div class="moz-cite-prefix">On 07.08.2014 22:20, Jon Masamitsu
          wrote:<br>
        </div>
        <blockquote cite="mid:53E3C37D.6010406@oracle.com" type="cite">
          <meta content="text/html; charset=windows-1251"
            http-equiv="Content-Type">
          <br>
          <div class="moz-cite-prefix">On 08/07/2014 03:01 AM, Dmitry
            Fazunenko wrote:<br>
          </div>
          <blockquote cite="mid:53E34E67.5060809@oracle.com" type="cite">
            <meta content="text/html; charset=windows-1251"
              http-equiv="Content-Type">
            Jon,<br>
            <br>
            Thanks for looking!<br>
            I love printing as much debug info as possible. But in this
            case I have nothing to add.<br>
            BTW, the deduplication tests are full of various
            System.out.prinltn(), so I think the it will be enough
            information in case of failure.<br>
            <br>
            I modified a little the code to make test fail. The jtr is
            attached. Please let me know if you believe that more data
            need to be printed.<br>
          </blockquote>
          <br>
          Yes, lots of output on failures.  I looked for some output
          that told<br>
          me the addresses of the two strings (the two that don't
          verify)<br>
          and the addresses of their char arrays.  I couldn't find it. 
          <br>
          I think if I were debugging a failure, that's the first thing
          I would<br>
          want to see.<br>
          <br>
          Jon<br>
          <br>
          <blockquote cite="mid:53E34E67.5060809@oracle.com" type="cite">
            <br>
            Thanks,<br>
            Dima<br>
            <br>
            <div class="moz-cite-prefix">On 06.08.2014 23:56, Jon
              Masamitsu wrote:<br>
            </div>
            <blockquote cite="mid:53E2885B.6040609@oracle.com"
              type="cite">
              <meta content="text/html; charset=windows-1251"
                http-equiv="Content-Type">
              Dima,<br>
              <br>
              If the test fails, can you print the strings with
              System.out.println() or<br>
              System.err.println()?  Any information about the strings
              might be<br>
              useful to understand why deduplication didn't work or why
              the<br>
              test thinks the deduplication didn't work (in case
              something<br>
              happens that the test doesn't expect)?  <br>
              <br>
              Jon<br>
              <br>
              <div class="moz-cite-prefix">On 8/6/2014 8:53 AM, Dmitry
                Fazunenko wrote:<br>
              </div>
              <blockquote cite="mid:53E24F6F.5000704@oracle.com"
                type="cite">
                <meta http-equiv="content-type" content="text/html;
                  charset=windows-1251">
                Hi, <br>
                <br>
                Would you please look at the simple fix of String
                Deduplication tests. <br>
                <br>
                Description:<br>
                <br>
                When string deduplication has happened  <i>s1.equals(s2)</i> 
                will be equivalent to <i>s1 == s2</i><br>
                Deduplication is performed in a separate thread so it
                could be delayed a bit.<br>
                Tests are away about possible delay and give another
                chance if deduplication hasn't <br>
                happened by the moment of check.<br>
                But tests wait for deduplication in infinitive loop, so
                if deduplication doesn't work the tests <br>
                will timeout, leaving hanging VM after. Which is not
                very elegant.<br>
                <br>
                The fix is simple: replace infinitive loops with limited
                ones and report failure.<br>
                The logic of the tests hasn't changed. <br>
                <br>
                <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Edfazunen/8050464/webrev.01/">http://cr.openjdk.java.net/~dfazunen/8050464/webrev.01/</a><br>
                <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://bugs.openjdk.java.net/browse/JDK-8050464">https://bugs.openjdk.java.net/browse/JDK-8050464</a><br>
                <br>
                Any comments are welcome.<br>
                <br>
                Thanks,<br>
                Dima<br>
                <br>
                <br>
                <br>
              </blockquote>
              <br>
            </blockquote>
            <br>
          </blockquote>
          <br>
        </blockquote>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>