<div dir="ltr"><div><div><div>> Seems like you must have backported the HB code to JDK 8u ?<br>Yes, we did.<br><br>> However a similar end result is the goal ...<br></div>Let me know if I can help this process in any way.<br><br></div>Best regards,<br></div>Dmitry Batrak<br><div><div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 18, 2017 at 9:21 PM, Phil Race <span dir="ltr"><<a href="mailto:philip.race@oracle.com" target="_blank">philip.race@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    Hi,<br>
    <br>
    If you read the bug here I wrote :<br>
    >Note that harfbuzz still will likely copy and sanitise the table
    each time
    <br>
    >we create a face object but fixing that needs a deeper
    understanding
    <br>
    >(perhaps too deep) of how we can re-use harfbuzz objects across
    <br>
    > calls to shape. Something to consider later<br>
    <br>
    So I am aware that we are taking a per-call overhead of rebuilding
    this info and today's fix<br>
    is a lower-cost / risk step towards reducing that.<br>
    I needed to take a closer look at the lifecycle and sharability of
    these structures before<br>
    doing anything but don't have time right now. Eg, it isn't clear to
    me if your code is thread safe.<br>
    <br>
    Also I intend to remove the ICU code as obsolete and the caching
    code I am using in<br>
    this fix was then going to look like dead code so I wanted to make
    sure it was hooked up<br>
    into HB and serving a purpose before that removal.<br>
    <br>
    Seems like you must have backported the HB code to JDK 8u ?<br>
    Or are you already shipping JDK 9 based OpenJDK ?<br>
    <br>
    <br>
    But in summary, yes, the general idea you propose is something that
    is "on the list".<br>
    Probably some lines of what you have in that webrev can be adopted
    but I don't<br>
    yet have a view on whether it should all be adopted directly.<br>
    However a similar end result is the goal ..<br>
    <br>
    -phil.<br>
    <br>
    <br>
    <div class="m_-4207892805503292338moz-cite-prefix">On 08/18/2017 02:31 AM, Dmitry Batrak
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>
                <div>
                  <div>Hello,<br>
                    <br>
                  </div>
                  I was going to propose a related change a bit later,
                  but thought it makes sense to let you know now, as
                  you're working on a similar thing.<br>
                  <br>
                </div>
                In our OpenJDK-based runtime, we've optimized HarfBuzz
                invocations, by creating hb_face_t object only once per
                Font2D instance. <br>
                This can make layout 2-3 times faster (more prominent
                for fonts with a lot of layout rules, e.g. Fira Code).<br>
              </div>
              We have this working in production for about a year now,
              without issues.<br>
              <br>
            </div>
            I've created a corresponding webrev here <br>
              <a href="http://cr.openjdk.java.net/%7Edbatrak/hb-optimization/webrev.00/" target="_blank">http://cr.openjdk.java.net/~<wbr>dbatrak/hb-optimization/<wbr>webrev.00/</a><br>
          </div>
          It's generated 'as is', it should probably be reworked, if
          it's going to be included in OpenJDK. In particular, caching
          of hb_face_t objects<br>
        </div>
        should probably be encapsulated in SunLayoutEngine, and not done
        in Font2D object directly.<br>
        <br>
        <div>
          <div>
            <div>
              <div>
                <div>
                  <div>
                    <div>I'm ready to work on the change further,
                      following the formal procedure (raising the
                      ticket, submitting RFRs, etc). So, please let me
                      know<br>
                    </div>
                    <div>if you're interested, and whether you have any
                      comments or suggestions. In any case, I'll require
                      someone sponsoring this change,<br>
                    </div>
                    <div>as I don't have a Committer status.<br>
                      <br>
                    </div>
                    <div>Best regards,<br>
                    </div>
                    <div>Dmitry Batrak<br>
                    </div>
                    <div><br>
                    </div>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </div>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Thu, Aug 17, 2017 at 12:07 AM,
            Phil Race <span dir="ltr"><<a href="mailto:philip.race@oracle.com" target="_blank">philip.race@oracle.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Bug: <a href="https://bugs.openjdk.java.net/browse/JDK-8186317" rel="noreferrer" target="_blank">https://bugs.openjdk.java.net/<wbr>browse/JDK-8186317</a><br>
              Webrev: <a href="http://cr.openjdk.java.net/%7Eprr/8186317/" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/~pr<wbr>r/8186317/</a><br>
              <br>
              In the ICU code path, we cache the layout tables in native
              memory so that<br>
              when requested by ICU we can just hand the pointer, saving
              the overhead<br>
              of copying the Java array for every call to layout.<br>
              <br>
              We weren't doing this for harfbuzz and this webrev fixes
              that.<br>
              <br>
              I noticed harfbuzz always retrieves the 'head' table so I
              decided to add that to the list of<br>
              cached tables.<br>
              <br>
              The overall result is something like 25-30% performance
              gain.<span class="m_-4207892805503292338HOEnZb"><font color="#888888"><br>
                  <br>
                  -phil.<br>
                </font></span></blockquote>
          </div>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
  </div>

</blockquote></div><br></div></div></div></div></div>