<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 2/26/14 7:15 AM, Staffan Larsen wrote:<br>
    <blockquote
      cite="mid:F9F51E64-23F0-4BF8-BF43-B4E2DF560A3F@oracle.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <br>
      <div>
        <div>On 26 feb 2014, at 15:03, Daniel D. Daugherty &lt;<a
            moz-do-not-send="true"
            href="mailto:daniel.daugherty@oracle.com">daniel.daugherty@oracle.com</a>&gt;
          wrote:</div>
        <br class="Apple-interchange-newline">
        <blockquote type="cite">
          <div style="font-size: 16px; font-style: normal; font-variant:
            normal; font-weight: normal; letter-spacing: normal;
            line-height: normal; orphans: auto; text-align: start;
            text-indent: 0px; text-transform: none; white-space: normal;
            widows: auto; word-spacing: 0px; -webkit-text-stroke-width:
            0px;">On 2/26/14 1:31 AM, Staffan Larsen wrote:<br>
            <blockquote type="cite">On 26 feb 2014, at 01:48, Daniel D.
              Daugherty &lt;<a moz-do-not-send="true"
                href="mailto:daniel.daugherty@oracle.com">daniel.daugherty@oracle.com</a>&gt;
              wrote:<br>
              <br>
              <blockquote type="cite">I concur with Markus. Pairing
                JVM_CONSTANT_UnresolvedClassInError with<br>
                JVM_CONSTANT_UnresolvedClass in the
                ConstantPool::copy_entry_to()<br>
                switch looks like the right thing to do.<br>
              </blockquote>
              Good - thanks.<br>
              <br>
              <blockquote type="cite">The usual questions:<br>
                <br>
                - why wasn't this failure mode seen before JDK8?<br>
              </blockquote>
              No tests for this ? ;)<br>
            </blockquote>
            <br>
            I should have been more clear... :-) Why hasn't the NetBeans
            profiler<br>
            run into this before? That profiler is a wonderful test for
            the<br>
            RedefineClasses/RetransformClasses stuff…</div>
        </blockquote>
        <div><br>
        </div>
        Ah, ok. No idea...</div>
      <div><br>
        <blockquote type="cite">
          <div style="font-size: 16px; font-style: normal; font-variant:
            normal; font-weight: normal; letter-spacing: normal;
            line-height: normal; orphans: auto; text-align: start;
            text-indent: 0px; text-transform: none; white-space: normal;
            widows: auto; word-spacing: 0px; -webkit-text-stroke-width:
            0px;"><br>
            <br>
            <blockquote type="cite"><br>
              <blockquote type="cite">- was this failure caught
                somewhere else before JDK8 and changes<br>
                 in JDK8 exposed a new code path?<br>
                <br>
                Reasoning about this from a 30,000 foot view, I don't
                see any reason<br>
                why you can't redefine a class that has a constant pool
                ref that<br>
                refers to a class in error. You won't be able to use the
                error'ed<br>
                class, but there's no reason it can't be in there... Or
                does that<br>
                violate the rule that you can't redefine a class that
                isn't fully<br>
                linked (what ever that means...)???<br>
                <br>
                So what does your new test on JDK7 or JDK6? Just
                curious…<br>
              </blockquote>
              The test passes on jdk7, but fails on jdk8. (I don’t have
              a jdk6). I don’t know why it passes on jdk7, do you think
              it’s important to track it down?<br>
            </blockquote>
            <br>
            The fact that it passes on JDK7 is the useful piece of data.<br>
            Figuring out why is much less important. BTW, which JDK7<br>
            version? One of the updates or GA/FCS?<br>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>I used 7u45, but now I tested with 7u4 as well - passes
          there, too.</div>
      </div>
    </blockquote>
    <br>
    <tt>Sounds like the change/breakage is limited to JDK8 so that's<br>
      a relief.<br>
      <br>
      <br>
    </tt>
    <blockquote
      cite="mid:F9F51E64-23F0-4BF8-BF43-B4E2DF560A3F@oracle.com"
      type="cite">
      <div>
        <div><br>
        </div>
        <div>Are you ok with pushing the change?</div>
      </div>
    </blockquote>
    <br>
    <tt>Very much so.<br>
      <br>
      Dan<br>
      <br>
      <br>
    </tt>
    <blockquote
      cite="mid:F9F51E64-23F0-4BF8-BF43-B4E2DF560A3F@oracle.com"
      type="cite">
      <div>
        <div><br>
        </div>
        <div>
          <div>Thanks,</div>
          <div>/Staffan</div>
        </div>
        <br>
        <blockquote type="cite">
          <div style="font-size: 16px; font-style: normal; font-variant:
            normal; font-weight: normal; letter-spacing: normal;
            line-height: normal; orphans: auto; text-align: start;
            text-indent: 0px; text-transform: none; white-space: normal;
            widows: auto; word-spacing: 0px; -webkit-text-stroke-width:
            0px;"><br>
            Dan<br>
            <br>
            <br>
            <blockquote type="cite"><br>
              /Staffan<br>
              <br>
              <blockquote type="cite">Dan<br>
                <br>
                <br>
                On 2/24/14 2:42 AM, Markus Gronlund wrote:<br>
                <blockquote type="cite">Hi Staffan,<br>
                  <br>
                  I would think this is the correct fix.<br>
                  <br>
                  The other two constant pool "error" tags, besides
                  UnresolvedClassInError, which signal constant pool
                  resolution errors are MethodTypeInError and
                  MethodHandleInError - these error tags are associated
                  with their corresponding "success" tags in switch
                  targets in ConstantPool::copy_entry_to(), as well as
                  in additional routines in constantPool.cpp.<br>
                  <br>
                  In addition, in other routines in ConstantPool.cpp,
                  the error tag JVM_CONSTANT_UnresolvedClassInError is
                  associated with JVM_CONSTANT_UnresolvedClass -
                   ConstantPool::resolve_constant_at_impl() for example.<br>
                  <br>
                  Thanks<br>
                  Markus<br>
                  <br>
                  <br>
                  -----Original Message-----<br>
                  From: Staffan Larsen<br>
                  Sent: den 21 februari 2014 15:11<br>
                  To: hotspot-runtime-dev; <a moz-do-not-send="true"
                    href="mailto:serviceability-dev@openjdk.java.net">serviceability-dev@openjdk.java.net</a>
                  <a moz-do-not-send="true"
                    href="mailto:serviceability-dev@openjdk.java.net">serviceability-dev@openjdk.java.net</a><br>
                  Subject: RFR: 8035150 ShouldNotReachHere() in
                  ConstantPool::copy_entry_to<br>
                  <br>
                  This is an attempt to solve a crash while redefining a
                  class that has unresolved class references in its
                  constant pool. I would appreciate some extra scrutiny
                  here since I am unfamiliar with this code path.<br>
                  <br>
                  I have also added a test that causes a JVM crash
                  without the fix.<br>
                  <br>
                  The updates to the test library is all code copied
                  from the jdk version of the test library.<br>
                  <br>
                  webrev: <a moz-do-not-send="true"
                    href="http://cr.openjdk.java.net/%7Esla/8035150/webrev.00/">http://cr.openjdk.java.net/~sla/8035150/webrev.00/</a><br>
                  bug: <a moz-do-not-send="true"
                    href="https://bugs.openjdk.java.net/browse/JDK-8035150">https://bugs.openjdk.java.net/browse/JDK-8035150</a><br>
                  <br>
                  Thanks,<br>
                  /Staffan</blockquote>
              </blockquote>
            </blockquote>
          </div>
        </blockquote>
      </div>
      <br>
    </blockquote>
    <br>
  </body>
</html>