<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Am 30.09.2011 22:46, schrieb Xueming Shen:
    <blockquote cite="mid:4E862AB2.7090605@oracle.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      On 09/30/2011 07:09 AM, Ulf Zibis wrote:
      <blockquote cite="mid:4E85CD9D.1050401@gmx.de" type="cite">
        <blockquote cite="mid:4E83E591.2090103@oracle.com" type="cite">
          <br>
          (1) new byte[]{(byte)0xE1, (byte)0x80, (byte)0x42} ---&gt;
          CoderResult.malformedForLength(1)<br>
          It appears the Unicode Standard now explicitly recommends to
          return the malformed length 2,<br>
          what UTF-8 is doing now, for this scenario<br>
        </blockquote>
        My idea behind was, that in case of malformed length 1 a
        consecutive call to the decode loop would again return another
        malformed length 1, to ensure 2 replacement chars in the output
        string. (Not sure, if that is expected in this corner case.)</blockquote>
      <br>
      Unicode Standard's "best practices" D93a/b recommends to return 2
      in this case.<br>
    </blockquote>
    Can you please give me a link for D93a/a. I don't know, where to
    find it.<br>
    <br>
    <br>
    <blockquote cite="mid:4E862AB2.7090605@oracle.com" type="cite"> <br>
      <br>
      <blockquote cite="mid:4E85CD9D.1050401@gmx.de" type="cite">3.
        Consider additionally <a moz-do-not-send="true"
          href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6795537"><font
            face="">6795537</font> - <font face="">UTF_8$Decoder
            returns wrong results</font></a><br>
        <br>
        <br>
        <blockquote cite="mid:4E83E591.2090103@oracle.com" type="cite">
          I'm not sure I&nbsp; understand the suggested&nbsp; b1 &lt; -0x3e patch,
          I don't see we can simply replace<br>
          ((b1 &gt;&gt; 5) == -2) with (b1 &lt; -0x3e).<br>
        </blockquote>
        You must see the b1 &lt; -0x3e in combination with the following
        b1 &lt; -0x20. ;-)<br>
        <br>
        But now I have a better "if...else if" switch. :-)<br>
        - saves the shift operations<br>
        - only 1 comparison per case<br>
        - only 1 constant to load per case<br>
        - helps compiler to benefit from 1 byte constants and op-codes<br>
        - much better readable<br>
      </blockquote>
      <br>
      I believe we changed from (b1 &lt; xyz) to (b1 &gt;&gt; x) == -2
      back to 2009(?) because<br>
      the benchmark shows the "shift" version is slightly faster.</blockquote>
    IIRC this was only about a shift by multiples of 8 to ensure an
    1-byte comparison of 16/32-byte values in the double/quad-byte
    charsets.<br>
    <br>
    <br>
    <blockquote cite="mid:4E862AB2.7090605@oracle.com" type="cite"> Do
      you have any number<br>
      shows any difference now. My non-scientific benchmark still
      suggests the "shift"<br>
      type is faster on -server vm, no significant difference on -client
      vm.<br>
      <br>
      &nbsp; ------------------&nbsp; your new switch---------------<br>
      (1) -server<br>
      Method&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Millis&nbsp; Ratio<br>
      Decoding 1b UTF-8 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 125&nbsp; 1.000<br>
      Decoding 2b UTF-8 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2558 20.443<br>
      Decoding 3b UTF-8 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3439 27.481<br>
      Decoding 4b UTF-8 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2030 16.221<br>
      (2) -client<br>
      Decoding 1b UTF-8 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 335&nbsp; 1.000<br>
      Decoding 2b UTF-8 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1041&nbsp; 3.105<br>
      Decoding 3b UTF-8 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2245&nbsp; 6.694<br>
      Decoding 4b UTF-8 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1254&nbsp; 3.741<br>
      <br>
      &nbsp; ------------------ existing "shift"---------------<br>
      (1) -server<br>
      Decoding 1b UTF-8 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 134&nbsp; 1.000<br>
      Decoding 2b UTF-8 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1891 14.106<br>
      Decoding 3b UTF-8 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2934 21.886<br>
      Decoding 4b UTF-8 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2133 15.913<br>
      (2) -client<br>
      Decoding 1b UTF-8 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 341&nbsp; 1.000<br>
      Decoding 2b UTF-8 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 949&nbsp; 2.560<br>
      Decoding 3b UTF-8 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2321&nbsp; 6.255<br>
      Decoding 4b UTF-8 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1278&nbsp; 3.446<br>
      <br>
    </blockquote>
    Very interesting and surprising numbers!<br>
    The most surprising is, that the client compiler generates faster
    code for 2..4-byte codes. I think, we should ask the HotSpot team
    for help. As the UTF-8 de/encoding is a very frequent task, HotSpot
    should provide compiled code as optimized best as possible for UTF-8
    de/encoding.<br>
    Another surprise is, that benchmark for 1b UTF-8 is not same for
    "new switch" and "shift" version, as the ASCII only loop is the same
    in both versions.<br>
    To discover the miracle, why the"shift" version is little faster
    than the "new switch" version, it should be helpful, to see the
    disassembling of the HotSpot compiled code.<br>
    A third version, using the "(b1 &amp; 0xe0) == 0xc0"/"(b1 &amp;
    0xf0) == 0xe0"/"(b1 &amp; 0xf8) == 0xf0" pattern, should be
    interesting toofor the benchmark comparison.<br>
    <br>
    In my opinion it would be more significant to compare x 1..4-byte
    codes than y bytes of 1..4-byte codes. I.e. 1000 bytes of 1-byte
    codes against 2000 bytes of 2-byte codes against 3000 bytes of
    3-byte codes against 4000 bytes of 4-byte codes<br>
    <br>
    We should document somewhere, that the ESU-8 decoder is faster than
    the strong UTF-8 decoder for developers, who can ensure, that there
    are no invalid surrogates in their source bytes.<br>
    <br>
    -Ulf<br>
    <br>
  </body>
</html>