[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-serviceability-dev
Subject: Re: RFR: 8035150 ShouldNotReachHere() in ConstantPool::copy_entry_to
From: Staffan Larsen <staffan.larsen () oracle ! com>
Date: 2014-02-26 14:33:22
Message-ID: 4BECFB25-0704-40DE-AFC7-0948DD6531AF () oracle ! com
[Download RAW message or body]
Thanks Dan and Markus!
On 26 feb 2014, at 15:28, Daniel D. Daugherty <daniel.daugherty@oracle.com> wrote:
> On 2/26/14 7:15 AM, Staffan Larsen wrote:
> >
> > On 26 feb 2014, at 15:03, Daniel D. Daugherty <daniel.daugherty@oracle.com> \
> > wrote:
> > > On 2/26/14 1:31 AM, Staffan Larsen wrote:
> > > > On 26 feb 2014, at 01:48, Daniel D. Daugherty <daniel.daugherty@oracle.com> \
> > > > wrote:
> > > > > I concur with Markus. Pairing JVM_CONSTANT_UnresolvedClassInError with
> > > > > JVM_CONSTANT_UnresolvedClass in the ConstantPool::copy_entry_to()
> > > > > switch looks like the right thing to do.
> > > > Good - thanks.
> > > >
> > > > > The usual questions:
> > > > >
> > > > > - why wasn't this failure mode seen before JDK8?
> > > > No tests for this ? ;)
> > >
> > > I should have been more clear... :-) Why hasn't the NetBeans profiler
> > > run into this before? That profiler is a wonderful test for the
> > > RedefineClasses/RetransformClasses stuff…
> >
> > Ah, ok. No idea...
> >
> > >
> > >
> > > >
> > > > > - was this failure caught somewhere else before JDK8 and changes
> > > > > in JDK8 exposed a new code path?
> > > > >
> > > > > Reasoning about this from a 30,000 foot view, I don't see any reason
> > > > > why you can't redefine a class that has a constant pool ref that
> > > > > refers to a class in error. You won't be able to use the error'ed
> > > > > class, but there's no reason it can't be in there... Or does that
> > > > > violate the rule that you can't redefine a class that isn't fully
> > > > > linked (what ever that means...)???
> > > > >
> > > > > So what does your new test on JDK7 or JDK6? Just curious…
> > > > 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?
> > >
> > > The fact that it passes on JDK7 is the useful piece of data.
> > > Figuring out why is much less important. BTW, which JDK7
> > > version? One of the updates or GA/FCS?
> >
> > I used 7u45, but now I tested with 7u4 as well - passes there, too.
>
> Sounds like the change/breakage is limited to JDK8 so that's
> a relief.
>
>
> >
> > Are you ok with pushing the change?
>
> Very much so.
>
> Dan
>
>
> >
> > Thanks,
> > /Staffan
> >
> > >
> > > Dan
> > >
> > >
> > > >
> > > > /Staffan
> > > >
> > > > > Dan
> > > > >
> > > > >
> > > > > On 2/24/14 2:42 AM, Markus Gronlund wrote:
> > > > > > Hi Staffan,
> > > > > >
> > > > > > I would think this is the correct fix.
> > > > > >
> > > > > > 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.
> > > > > > 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.
> > > > > > Thanks
> > > > > > Markus
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Staffan Larsen
> > > > > > Sent: den 21 februari 2014 15:11
> > > > > > To: hotspot-runtime-dev; serviceability-dev@openjdk.java.net \
> > > > > > serviceability-dev@openjdk.java.net
> > > > > > Subject: RFR: 8035150 ShouldNotReachHere() in ConstantPool::copy_entry_to
> > > > > >
> > > > > > 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.
> > > > > > I have also added a test that causes a JVM crash without the fix.
> > > > > >
> > > > > > The updates to the test library is all code copied from the jdk version \
> > > > > > of the test library.
> > > > > > webrev: http://cr.openjdk.java.net/~sla/8035150/webrev.00/
> > > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8035150
> > > > > >
> > > > > > Thanks,
> > > > > > /Staffan
> >
>
[Attachment #3 (unknown)]
<html><head><meta http-equiv="Content-Type" content="text/html \
charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: \
space; -webkit-line-break: after-white-space;">Thanks Dan and \
Markus!<div><br><div><div>On 26 feb 2014, at 15:28, Daniel D. Daugherty <<a \
href="mailto:daniel.daugherty@oracle.com">daniel.daugherty@oracle.com</a>> \
wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type">
<div 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 <<a \
moz-do-not-send="true" \
href="mailto:daniel.daugherty@oracle.com">daniel.daugherty@oracle.com</a>> \
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 <<a moz-do-not-send="true" \
href="mailto:daniel.daugherty@oracle.com">daniel.daugherty@oracle.com</a>> \
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>
</div>
</blockquote></div><br></div></body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic