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

[serguei.spitsyn at oracle.com]

I need another reviewer for this.

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
>