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

[serguei.spitsyn at oracle.com]

Please, review the jdk 8u60 backport for:
   https://bugs.openjdk.java.net/browse/JDK-8067662

8u60 hotspot webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60

8u60 webrev for unit test update (the fix applies cleanly):
http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60



9 hotspot webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2

9 webrev for unit test update:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2


Summary:
   The 9 fix can not be applied cleanly so that I have to rework the fix 
a little bit.

   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.

Testing in progress:
   In progress: nsk redefine classes tests, JTREG java/lang/instrument


Thanks,
Serguei