On 2/26/14 7:15 AM, Staffan Larsen wrote:
On 26 feb 2014, at 15:03, Daniel D. Daugherty
<daniel.daughe...@oracle.com <mailto:daniel.daughe...@oracle.com>> wrote:
On 2/26/14 1:31 AM, Staffan Larsen wrote:
On 26 feb 2014, at 01:48, Daniel D. Daugherty
<daniel.daughe...@oracle.com <mailto:daniel.daughe...@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
<mailto:serviceability-dev@openjdk.java.net>
serviceability-dev@openjdk.java.net
<mailto: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/
<http://cr.openjdk.java.net/%7Esla/8035150/webrev.00/>
bug: https://bugs.openjdk.java.net/browse/JDK-8035150
Thanks,
/Staffan
