<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Martin,<br>
    <br>
    one comment:<br>
    <br>
    the count increment update should use release store + atomic update.<br>
    ref:
<a class="moz-txt-link-freetext" href="https://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming">https://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming</a><br>
    <br>
    Best Regards<br>
    Jamsheed<br>
    <br>
    <div class="moz-cite-prefix">On 4/6/2016 6:54 PM, Doerr, Martin
      wrote:<br>
    </div>
    <blockquote
      cite="mid:a390742c041b4803b1b0ebe63e7a3598@DEWDFE13DE14.global.corp.sap"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        color:black;
        mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0cm;
        margin-right:0cm;
        margin-bottom:0cm;
        margin-left:36.0pt;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        color:black;
        mso-fareast-language:EN-US;}
span.EmailStyle18
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.EmailStyle19
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
span.EmailStyle20
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.EmailStyle21
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
span.EmailStyle22
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.EmailStyle23
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
span.EmailStyle24
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:1600333863;
        mso-list-type:hybrid;
        mso-list-template-ids:1514199064 243931784 67567619 67567621 67567617 67567619 67567621 67567617 67567619 67567621;}
@list l0:level1
        {mso-level-start-at:0;
        mso-level-number-format:bullet;
        mso-level-text:-;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:"Calibri",sans-serif;
        mso-fareast-font-family:"Times New Roman";
        mso-bidi-font-family:"Times New Roman";}
@list l0:level2
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:"Courier New";}
@list l0:level3
        {mso-level-number-format:bullet;
        mso-level-text:\F0A7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:Wingdings;}
@list l0:level4
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:Symbol;}
@list l0:level5
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:"Courier New";}
@list l0:level6
        {mso-level-number-format:bullet;
        mso-level-text:\F0A7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:Wingdings;}
@list l0:level7
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:Symbol;}
@list l0:level8
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:"Courier New";}
@list l0:level9
        {mso-level-number-format:bullet;
        mso-level-text:\F0A7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:Wingdings;}
ol
        {margin-bottom:0cm;}
ul
        {margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal"><span style="color:#1F497D">Hi Jamsheed and
            all,<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>†</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">thanks
            for your explanation.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"><o:p>†</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">About
            Case 1:</span><span style="font-size:12.0pt;color:#1F497D"
            lang="EN-US"><o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">I
            basically agree with that reading _next==NULL or _count==0
            only leads to false negatives and is not critical.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">Yes,
            we could live with a few more false negatives on weak memory
            model platforms (even though this is not my preferred
            design).<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"><o:p>†</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">About
            Case 2:<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">What
            Iím missing on the readerís side of the _count field is
            something which prevents processors from speculatively
            loading the contents of the ExceptionCache.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"><o:p>†</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">In
            ExceptionCache::test_address, the _count only affects the
            control flow.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">PPC
            and ARM processors can predict branches which depend on the
            _count field and load speculatively from the pc and handler
            fields (which may be stale data!).<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">Due
            to out-of-order execution of the loads, it can actually
            happen, that the new _count value is observed, but stale
            data is read from pc and handler fields.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">I
            guess it is highly unlikely that we will ever observe this,
            but thereís no guarantee.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"><o:p>†</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">I
            think my concern about using non-volatile fields for the
            _exception_cache is also still valid.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">Nothing
            prevents C++ Compilers from loading the pointer twice from
            memory. They may expect to get the pointer to the same
            instance both times but actually get two different ones.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">For
            example, this may lead to the situation that
            handler_for_exception_and_pc uses one ExceptionCache
            instance for calling the match function and another one (du
            to reload of non-volatile field) for calling next().<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"><o:p>†</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">May
            other people would like to comment on this lengthy
            discussion as well?<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"><o:p>†</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">Best
            regards,<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">Martin<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"><o:p>†</o:p></span></p>
        <p class="MsoNormal"><span lang="EN-US"><o:p>†</o:p></span></p>
        <div>
          <div style="border:none;border-top:solid #E1E1E1
            1.0pt;padding:3.0pt 0cm 0cm 0cm">
            <p class="MsoNormal"><b><span
                  style="color:windowtext;mso-fareast-language:DE"
                  lang="EN-US">From:</span></b><span
                style="color:windowtext;mso-fareast-language:DE"
                lang="EN-US"> Jamsheed C m
                [<a class="moz-txt-link-freetext" href="mailto:jamsheed.c.m@oracle.com">mailto:jamsheed.c.m@oracle.com</a>]
                <br>
                <b>Sent:</b> Mittwoch, 6. April 2016 13:54<br>
                <b>To:</b> Doerr, Martin <a class="moz-txt-link-rfc2396E" href="mailto:martin.doerr@sap.com"><martin.doerr@sap.com></a>;
                <a class="moz-txt-link-abbreviated" href="mailto:hotspot-compiler-dev@openjdk.java.net">hotspot-compiler-dev@openjdk.java.net</a><br>
                <b>Subject:</b> Re: RFR(S): 8153267: nmethod's exception
                cache not multi-thread safe<o:p></o:p></span></p>
          </div>
        </div>
        <p class="MsoNormal"><o:p>†</o:p></p>
        <p class="MsoNormal">Hi Martin,<br>
          <br>
          On 4/6/2016 2:49 PM, Doerr, Martin wrote:<br>
          <br>
          <span style="font-size:12.0pt;mso-fareast-language:DE"><o:p></o:p></span></p>
        <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
          <p class="MsoNormal"><span style="color:#1F497D">Hi Jamsheed,</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">†</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">here
              are the cases of add_handler_for_exception_and_pc we
              should talk about:</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">†</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">Case
              1: A new ExceptionCache instance needs to get added.</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">The
              storestore barrier you have added is used in the
              constructor of the ExceptionCache and it releases the most
              critical fields of it. I think this is what you explained
              in [1] in your email below.</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">The
              new values of _count and _next fields are written
              afterwards and hence not covered by this release barrier.
              Readers of the _exception_cache may read _count==0 or
              _next==NULL.</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">One
              could argue that this is not critical, but I guess this
              was not intended?</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">†</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">At
              least the _exception_cache field needs to be volatile to
              prevent optimizers from breaking anything. This is always
              needed for fields which are accessed concurrently by
              multiple threads without locks (as the readers do).</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">I
              think releasing the completely initialized ExceptionCache
              instance is a much cleaner design.</span><o:p></o:p></p>
        </blockquote>
        <p class="MsoNormal"><span
            style="font-size:12.0pt;font-family:"Times New
            Roman",serif;mso-fareast-language:DE">Having count <
            actual entries, or having _next = null is OK (as there is
            always (locked)slow path to check again).<br>
            Quoting comment from read path.<br>
            <br>
            <o:p></o:p></span></p>
        <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
          <p class="MsoNormal"><span
              style="font-size:12.0pt;font-family:"Times New
              Roman",serif;mso-fareast-language:DE">† // We never
              grab a lock to read the exception cache, so we may<br>
              † // have false negatives. This is okay, as it can only
              happen during<br>
              † // the first few exception lookups for a given nmethod.<o:p></o:p></span></p>
        </blockquote>
        <p class="MsoNormal"><span
            style="font-size:12.0pt;font-family:"Times New
            Roman",serif;mso-fareast-language:DE">Weak memory
            platforms may have a few more false negatives. but isn't
            that OK ?<br>
            This helps us, as we can remove volatile from picture, and
            actually good for read paths.<br>
            <br>
            <br>
            <o:p></o:p></span></p>
        <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
          <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">†</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">Case
              2: An existing ExceptionCache instance gets a new entry.</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">In
              this case your storestore barrier is good to release all
              updated fields. However, we need to consider the readers,
              too. The _count field needs to be volatile and the load
              must acquire. Otherwise, stale data may get read by
              processors which perform loads on speculative paths.</span><o:p></o:p></p>
        </blockquote>
        <p class="MsoNormal"><span
            style="font-size:12.0pt;font-family:"Times New
            Roman",serif;mso-fareast-language:DE">storestore mem
            barrier handles this,† as count <= no of real entries.
            and there is always locked slow path to check again.
            <br>
            As said before, there may be a few more false negatives in
            weak memory platforms than strong ones.<br>
            <br>
            Best Regards,<br>
            Jamsheed<br>
            <br>
            <br>
            <o:p></o:p></span></p>
        <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
          <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">†</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">I
              have added the acquire barrier for the _count field here:</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"><a
                moz-do-not-send="true"
href="http://cr.openjdk.java.net/%7Emdoerr/8153267_exception_cache/webrev.01/"><a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~mdoerr/8153267_exception_cache/webrev.01/">http://cr.openjdk.java.net/~mdoerr/8153267_exception_cache/webrev.01/</a></a></span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">†</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">Does
              this answer your questions or is anything still unclear?</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">†</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">Best
              regards,</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">Martin</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">†</span><o:p></o:p></p>
          <p class="MsoNormal"><span lang="EN-US">†</span><o:p></o:p></p>
          <div>
            <div style="border:none;border-top:solid #E1E1E1
              1.0pt;padding:3.0pt 0cm 0cm 0cm">
              <p class="MsoNormal"><b><span
                    style="color:windowtext;mso-fareast-language:DE"
                    lang="EN-US">From:</span></b><span
                  style="color:windowtext;mso-fareast-language:DE"
                  lang="EN-US"> Jamsheed C m [<a moz-do-not-send="true"
                    href="mailto:jamsheed.c.m@oracle.com">mailto:jamsheed.c.m@oracle.com</a>]
                  <br>
                  <b>Sent:</b> Mittwoch, 6. April 2016 10:11<br>
                  <b>To:</b> Doerr, Martin <a moz-do-not-send="true"
                    href="mailto:martin.doerr@sap.com"><martin.doerr@sap.com></a>;
                  <a moz-do-not-send="true"
                    href="mailto:hotspot-compiler-dev@openjdk.java.net">hotspot-compiler-dev@openjdk.java.net</a><br>
                  <b>Subject:</b> Re: RFR(S): 8153267: nmethod's
                  exception cache not multi-thread safe</span><o:p></o:p></p>
            </div>
          </div>
          <p class="MsoNormal">†<o:p></o:p></p>
          <p class="MsoNormal">Thanks for the reply. trying to
            understand stuffs.<br>
            <br>
            <br>
            <br>
            <o:p></o:p></p>
          <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
            <p class="MsoNormal">void
              nmethod::add_handler_for_exception_and_pc(Handle
              exception, address pc, address handler) {<br>
              † // There are potential race conditions during exception
              cache updates, so we<br>
              † // must own the ExceptionCache_lock before doing ANY
              modifications. Because<br>
              † // we don't lock during reads, it is possible to have
              several threads attempt<br>
              † // to update the cache with the same data. We need to
              check for already inserted<br>
              † // copies of the current data before adding it.<br>
              <br>
              † MutexLocker ml(ExceptionCache_lock);<br>
              † ExceptionCache* target_entry =
              exception_cache_entry_for_exception(exception);<br>
              <br>
              † if (target_entry == NULL ||
              !target_entry->add_address_and_handler(pc,handler)) {<br>
              ††† target_entry = new
              ExceptionCache(exception,pc,handler);<br>
              ††† add_exception_cache_entry(target_entry);<br>
              † }<br>
              }<o:p></o:p></p>
          </blockquote>
          <p class="MsoNormal"><br>
            [1]there is a storestore mem barrier before count is updated
            in† add_address_and_handler<br>
            this ensure exception pc and handler address are updated
            before count is incremented† and† Exception cache entry is
            updated at ( nm->_exception_cache or in the list
            ec->_next ).<br>
            <br>
            <br>
            <br>
            <o:p></o:p></p>
          <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
            <p class="MsoNormal">address
              nmethod::handler_for_exception_and_pc(Handle exception,
              address pc) {<br>
              † // We never grab a lock to read the exception cache, so
              we may<br>
              † // have false negatives. This is okay, as it can only
              happen during<br>
              † // the first few exception lookups for a given nmethod.<br>
              † ExceptionCache* ec = exception_cache();<br>
              † while (ec != NULL) {<br>
              ††† address ret_val;<br>
              ††† if ((ret_val = ec->match(exception,pc)) != NULL) {<br>
              ††††† return ret_val;<br>
              ††† }<br>
              ††† ec = ec->next();<br>
              † }<br>
              † return NULL;<br>
              }<o:p></o:p></p>
          </blockquote>
          <p class="MsoNormal" style="margin-bottom:12.0pt"><br>
            and in read logic. we first check ec entry is available (non
            null check) before proceeding further.<br>
            if ec is non null and ec_type,excpetion pc, and handler are
            available by[1]. though count can be reordered and not
            updated with new value.<br>
            <br>
            this fixes the issue. why you think it doesn't?<br>
            <br>
            Best Regards,<br>
            Jamsheed<br>
            <br>
            <br>
            <o:p></o:p></p>
          <div>
            <p class="MsoNormal">On 4/5/2016 3:40 PM, Doerr, Martin
              wrote:<o:p></o:p></p>
          </div>
          <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
            <p class="MsoNormal">Hi Jamsheed,<o:p></o:p></p>
            <p class="MsoNormal">†<o:p></o:p></p>
            <p class="MsoNormal"><span lang="EN-US">thanks for pointing
                me to it. Interesting that you have found such a problem
                so shortly before me
              </span><span style="font-family:Wingdings" lang="EN-US">J</span><o:p></o:p></p>
            <p class="MsoNormal"><span lang="EN-US">†</span><o:p></o:p></p>
            <p class="MsoNormal"><span lang="EN-US">My webrev addresses
                some aspects which are not covered by your fix:</span><o:p></o:p></p>
            <p class="MsoListParagraph"
              style="text-indent:-18.0pt;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span
                style="mso-list:Ignore">-<span style="font:7.0pt
                  "Times New Roman"">†††††††††
                </span></span><!--[endif]--><span lang="EN-US">add_handler_for_exception_and_pc
                adds a new ExceptionCache instance in the other case.
                They need to get released as well.</span><o:p></o:p></p>
            <p class="MsoListParagraph"
              style="text-indent:-18.0pt;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span
                style="mso-list:Ignore">-<span style="font:7.0pt
                  "Times New Roman"">†††††††††
                </span></span><!--[endif]--><span lang="EN-US">The
                readers of the _exception_cache field are not safe, yet.
                As Andrew Haley pointed out, optimizers may modify load
                accesses for non-volatile fields.</span><o:p></o:p></p>
            <p class="MsoNormal"><span lang="EN-US">†</span><o:p></o:p></p>
            <p class="MsoNormal"><span lang="EN-US">So I think my change
                is still needed.</span><o:p></o:p></p>
            <p class="MsoNormal"><span lang="EN-US">†</span><o:p></o:p></p>
            <p class="MsoNormal"><span lang="EN-US">And after taking a
                closer look at your change, I think the _count field
                which is addressed by your fix needs to be volatile as
                well. I can incorporate that in my change if you like.</span><o:p></o:p></p>
            <p class="MsoNormal"><span lang="EN-US">Would you agree?</span><o:p></o:p></p>
            <p class="MsoNormal"><span lang="EN-US">†</span><o:p></o:p></p>
            <p class="MsoNormal"><span lang="EN-US">Best regards,</span><o:p></o:p></p>
            <p class="MsoNormal"><span lang="EN-US">Martin</span><o:p></o:p></p>
            <p class="MsoNormal"><span style="color:#1F497D"
                lang="EN-US">†</span><o:p></o:p></p>
            <p class="MsoNormal"><span lang="EN-US">†</span><o:p></o:p></p>
            <div>
              <div style="border:none;border-top:solid #E1E1E1
                1.0pt;padding:3.0pt 0cm 0cm 0cm">
                <p class="MsoNormal"><b><span
                      style="color:windowtext;mso-fareast-language:DE"
                      lang="EN-US">From:</span></b><span
                    style="color:windowtext;mso-fareast-language:DE"
                    lang="EN-US"> hotspot-compiler-dev [<a
                      moz-do-not-send="true"
                      href="mailto:hotspot-compiler-dev-bounces@openjdk.java.net"><a class="moz-txt-link-freetext" href="mailto:hotspot-compiler-dev-bounces@openjdk.java.net">mailto:hotspot-compiler-dev-bounces@openjdk.java.net</a></a>]
                    <b>On Behalf Of </b>Jamsheed C m<br>
                    <b>Sent:</b> Montag, 4. April 2016 08:14<br>
                    <b>To:</b> <a moz-do-not-send="true"
                      href="mailto:hotspot-compiler-dev@openjdk.java.net">hotspot-compiler-dev@openjdk.java.net</a><br>
                    <b>Subject:</b> Re: RFR(S): 8153267: nmethod's
                    exception cache not multi-thread safe</span><o:p></o:p></p>
              </div>
            </div>
            <p class="MsoNormal">†<o:p></o:p></p>
            <p class="MsoNormal" style="margin-bottom:12.0pt">Hi Martin,<br>
              <br>
              "nmethod's exception cache not multi-thread safe"† bug is
              fixed in b107<br>
              bug id: <a moz-do-not-send="true"
                href="https://bugs.openjdk.java.net/browse/JDK-8143897">https://bugs.openjdk.java.net/browse/JDK-8143897</a><br>
              fix changeset: <a moz-do-not-send="true"
                href="http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/f918c20107d9">
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/f918c20107d9</a><br>
              discussion link: <a moz-do-not-send="true"
href="http://openjdk.5641.n7.nabble.com/RFR-XS-8143897-Weblogic12medrec-assert-handler-address-SharedRuntime-compute-compiled-exc-handler-nme-td255611.html">http://openjdk.5641.n7.nabble.com/RFR-XS-8143897-Weblogic12medrec-assert-handler-address-SharedRuntime-compute-compiled-exc-handler-nme-td255611.html</a><br>
              <br>
              Best Regards,<br>
              Jamsheed<o:p></o:p></p>
            <div>
              <p class="MsoNormal">On 4/1/2016 6:07 PM, Doerr, Martin
                wrote:<o:p></o:p></p>
            </div>
            <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
              <p class="MsoNormal" style="text-autospace:none"><span
                  style="font-family:"Courier New""
                  lang="EN-US">Hello everyone,</span><o:p></o:p></p>
              <p class="MsoNormal" style="text-autospace:none"><span
                  style="font-family:"Courier New""
                  lang="EN-US">†</span><o:p></o:p></p>
              <p class="MsoNormal" style="text-autospace:none"><span
                  style="font-family:"Courier New""
                  lang="EN-US">we have found a concurrency problem with
                  the nmethodís exception cache. Readers of the cache
                  may read stale data on weak memory platforms.</span><o:p></o:p></p>
              <p class="MsoNormal" style="text-autospace:none"><span
                  style="font-family:"Courier New""
                  lang="EN-US">†</span><o:p></o:p></p>
              <p class="MsoNormal" style="text-autospace:none"><span
                  style="font-family:"Courier New""
                  lang="EN-US">The writers of the cache are synchronized
                  by locks, but there may be concurrent readers: The
                  compiler runtimes use
                  nmethod::handler_for_exception_and_pc to access the
                  cache without locking.</span><o:p></o:p></p>
              <p class="MsoNormal" style="text-autospace:none"><span
                  style="font-family:"Courier New""
                  lang="EN-US">Therefore, the nmethod's field
                  _exception_cache needs to be volatile and adding new
                  entries must be done by releasing stores. (Loading
                  seems to be fine without acquire because there's an
                  address dependency from the load of the cache to the
                  usage of its contents which is sufficient to ensure
                  ordering on all openjdk platforms.)</span><o:p></o:p></p>
              <p class="MsoNormal" style="text-autospace:none"><span
                  style="font-family:"Courier New""
                  lang="EN-US">†</span><o:p></o:p></p>
              <p class="MsoNormal" style="text-autospace:none"><span
                  style="font-family:"Courier New""
                  lang="EN-US">I also added a minor cleanup: I changed
                  nmethod::is_alive to read the volatile field _state
                  only once. It is certainly undesired to force the
                  compiler to load it from memory twice.</span><o:p></o:p></p>
              <p class="MsoNormal" style="text-autospace:none"><span
                  style="font-family:"Courier New""
                  lang="EN-US">†</span><o:p></o:p></p>
              <p class="MsoNormal" style="text-autospace:none"><span
                  style="font-family:"Courier New""
                  lang="EN-US">Webrev is here:</span><o:p></o:p></p>
              <p class="MsoNormal" style="text-autospace:none"><span
                  style="font-family:"Courier New""
                  lang="EN-US"><a moz-do-not-send="true"
href="http://cr.openjdk.java.net/%7Emdoerr/8153267_exception_cache/webrev.00/">http://cr.openjdk.java.net/~mdoerr/8153267_exception_cache/webrev.00/</a></span><o:p></o:p></p>
              <p class="MsoNormal" style="text-autospace:none"><span
                  style="font-family:"Courier New""
                  lang="EN-US">†</span><o:p></o:p></p>
              <p class="MsoNormal" style="text-autospace:none"><span
                  style="font-family:"Courier New""
                  lang="EN-US">Please review. I will also need a
                  sponsor.</span><o:p></o:p></p>
              <p class="MsoNormal" style="text-autospace:none"><span
                  style="font-family:"Courier New""
                  lang="EN-US">†</span><o:p></o:p></p>
              <p class="MsoNormal" style="text-autospace:none"><span
                  style="font-family:"Courier New"">Best
                  regards,</span><o:p></o:p></p>
              <p class="MsoNormal" style="text-autospace:none"><span
                  style="font-family:"Courier New"">Martin</span><o:p></o:p></p>
              <p class="MsoNormal">†<o:p></o:p></p>
            </blockquote>
            <p class="MsoNormal"><span style="font-size:12.0pt">†</span><o:p></o:p></p>
          </blockquote>
          <p class="MsoNormal"><span style="font-size:12.0pt">†</span><o:p></o:p></p>
        </blockquote>
        <p class="MsoNormal"><span
            style="font-size:12.0pt;font-family:"Times New
            Roman",serif;mso-fareast-language:DE"><o:p>†</o:p></span></p>
      </div>
    </blockquote>
    <br>
  </body>
</html>