RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement.<init>

[Coleen Phillimore]

On 3/13/15, 2:37 PM, Coleen Phillimore wrote:
>
> On 3/13/15, 2:36 PM, serguei.spitsyn at 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.spitsyn at 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
>>>
>>
>