<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hi Markus,<br>
      <br>
      The fix is good.<br>
      <br>
      On 2/21/14 1:11 PM, Vladimir Kozlov wrote:<br>
    </div>
    <blockquote cite="mid:5307C10E.1070307@oracle.com" type="cite">Indent
      is off:
      <br>
      <br>
      +&nbsp; if (!_jvmti_can_access_local_variables &amp;&amp;
      <br>
      +&nbsp;&nbsp;&nbsp; JvmtiExport::can_access_local_variables()) {
      <br>
    </blockquote>
    <br>
    Also, the return statements there have incorrect indent 4.<br>
    <br>
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <pre><span class="new">+bool ciEnv::jvmti_state_changed() const {</span>
<span class="new">+  if (!_jvmti_can_access_local_variables &amp;&amp;</span>
<span class="new">+    JvmtiExport::can_access_local_variables()) {</span>
<span class="new">+      return true;</span>
<span class="new">+  }</span>
<span class="new">+  if (!_jvmti_can_hotswap_or_post_breakpoint &amp;&amp;</span>
<span class="new">+    JvmtiExport::can_hotswap_or_post_breakpoint()) {</span>
<span class="new">+      return true;</span>
<span class="new">+  }</span>
<span class="new">+  if (!_jvmti_can_post_on_exceptions &amp;&amp;</span>
<span class="new">+    JvmtiExport::can_post_on_exceptions()) {</span>
<span class="new">+      return true;</span>
<span class="new">+  }</span>
<span class="new">+  if (!_jvmti_can_pop_frame &amp;&amp;</span>
<span class="new">+    JvmtiExport::can_pop_frame()) {</span>
<span class="new">+      return true;</span>
<span class="new">+  }</span>
<span class="new">+  return false;</span>
 }</pre>
    <br>
    Thanks,<br>
    Serguei<br>
    <br>
    <blockquote cite="mid:5307C10E.1070307@oracle.com" type="cite">
      <br>
      otherwise it is good.
      <br>
      <br>
      Thanks,
      <br>
      Vladimir
      <br>
      <br>
      On 2/21/14 12:27 PM, Markus Gronlund wrote:
      <br>
      <blockquote type="cite">Hi Vladimir,
        <br>
        <br>
        You are absolutely right, many thanks for pointing it out - I
        should have inspected that more closely...
        <br>
        <br>
        Updated:
        <br>
        <br>
        <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~mgronlun/8035493/webrev02/">http://cr.openjdk.java.net/~mgronlun/8035493/webrev02/</a>
        <br>
        <br>
        <br>
        Thanks again
        <br>
        Best regards
        <br>
        <br>
        Markus
        <br>
        <br>
        <br>
        <br>
        -----Original Message-----
        <br>
        From: Vladimir Kozlov
        <br>
        Sent: den 21 februari 2014 19:06
        <br>
        To: Markus Gronlund; <a class="moz-txt-link-abbreviated" href="mailto:serviceability-dev@openjdk.net">serviceability-dev@openjdk.net</a>;
        hotspot-runtime-dev; <a class="moz-txt-link-abbreviated" href="mailto:hotspot-compiler-dev@openjdk.java.net">hotspot-compiler-dev@openjdk.java.net</a>
        <br>
        Subject: Re: RFR(S): 8035493: JVMTI PopFrame capability must
        instruct compilers not to prune locals
        <br>
        <br>
        Markus,
        <br>
        <br>
        jvmti_state_changed() produces different result than the code it
        replaced. If original jvmti cached values were true we did not
        bailout compilation regardless their current. Only with change
        from false to true we do that.
        <br>
        <br>
        Thanks,
        <br>
        Vladimir
        <br>
        <br>
        On 2/21/14 2:53 AM, Markus Gronlund wrote:
        <br>
        <blockquote type="cite">Greetings,
          <br>
          <br>
          Kindly asking for reviews for the following changeset:
          <br>
          <br>
          Webrev: <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~mgronlun/8035493/webrev01/">http://cr.openjdk.java.net/~mgronlun/8035493/webrev01/</a>
          <br>
          <br>
          Bug: <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8035493">https://bugs.openjdk.java.net/browse/JDK-8035493</a>
          <br>
          <br>
          Problem statement summary and details are outlined in bug
          JDK-8035493
          <a class="moz-txt-link-rfc2396E" href="https://bugs.openjdk.java.net/browse/JDK-8035493">&lt;https://bugs.openjdk.java.net/browse/JDK-8035493&gt;</a> .
          <br>
          <br>
          Testing completed:
          <br>
          <br>
          nsk/jvmti/scenarios/* (this includes JVMTI Hotswap and
          PopFrame
          <br>
          testing)
          <br>
          <br>
          hotspot/test/compiler/*
          <br>
          <br>
          Additionals:
          <br>
          <br>
          I would like, if possible, if we could move away from
          intertwining
          <br>
          specific jvmti capabilities inside the different compilers.
          <br>
          <br>
          The existing code makes it difficult to evolve and extend with
          <br>
          additional instructions to the compilers, esp. if we would
          like to
          <br>
          pass results from higher level conditions, perhaps by
          combining
          <br>
          contextual data with/without JVMTI. If possible, a suggestion
          would be
          <br>
          the creation of a higher level interface which the ciEnv can
          query for compilation instructions- the implementations of
          this interface could then be shielded away and allow for any
          type of combinatorial logic - leaving the code in the
          compilers themselves untouched.
          <br>
          <br>
          Thanks in advance
          <br>
          <br>
          Markus
          <br>
          <br>
        </blockquote>
      </blockquote>
    </blockquote>
    <br>
  </body>
</html>