On 3/13/15, 2:37 PM, Coleen Phillimore wrote:
On 3/13/15, 2:36 PM, serguei.spit...@oracle.com wrote:
Coleen,
Thank you for review and great idea to use the method name cp index!
However, this approach is going stop working if we get rid of the CP
merge in the future.
Yes, it will. I was just thinking about how to resolve that. We'll
have to brainstorm this in the summer.
There's still a huge snowbank outside my window, but I've been thinking
about this.
I have been working on the enhanced class redefinition sources. This is
how we can resolve the stack trace problem, which is better than what we
have today:
When we do a class redefinition with enhanced class redefinition, we
walk the heap to replace oop->_klass fields with the new classes. We
replace a few other things too. We can change backtraces to have the
Method* again and when we walk the heap during redefinition, we can also
build a GrowableArray of all Method* found in the backtraces.
This GrowableArray of Method* can be used to mark the Method* on_stack
so that they are not deallocated during class unloading. If the method
isn't deallocated, neither is the old class where it came from. This is
good because we can get the line number at bci and source file name also
from the old Method*.
Coleen
Coleen
Thanks,
Serguei
On 3/13/15 10:40 AM, Coleen Phillimore wrote:
Serguei,
This looks good. This works a lot harder to find the original
method than the code used to.
Thanks,
Coleen
On 3/13/15, 1:27 AM, serguei.spit...@oracle.com wrote:
Please, review the jdk 9 fix for:
https://bugs.openjdk.java.net/browse/JDK-8067662
Open hotspot webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.1/
Open webrev for unit test update:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.1/
Summary:
An NPE is trown in a thread dumping via JMX when doing CPU
profiling in NetBeans Profiler and VisualVM.
The issue is that the methods and related klass versions are not
kept alive if a class redefinition
takes place between catching a Throwable and taking a thread dump.
It can result in loosing an obsolete method, and so, the
reconstruction of method name becomes impossible.
In such a case, the null reference is returned instead of a valid
method name.
The solution is to use current klass version and method
orig_idnum instead of ordinary method idnum
to find required method pointer. In the worst case when the
related klass version is gone
(was not included to or was removed from the previous_versions
linked list), a saved method name
CP index of the latest klass version can be used to restore the
method name.
The footprint extra overhead for this approach is u2 per stack
frame.
The plan is also to backport the fix to 8u60.
Testing:
In progress: nsk redefine classes tests, JTREG java/lang/instrument
Thanks,
Serguei
