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

[Coleen Phillimore]

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