"java.lang.NullPointerException: Method name is null" from StackTraceElement.<init>

We see strange NPE when taking Thread-dump via JMX when doing CPU profiling in NetBeans Profiler and VisualVM.
The NPE looks like this:

java.lang.NullPointerException: Method name is null
at java.util.Objects.requireNonNull(Objects.java:228)
at java.lang.StackTraceElement.<init>(StackTraceElement.java:72)
at sun.management.StackTraceElementCompositeData.from(StackTraceElementCompositeData.java:55)
at sun.management.ThreadInfoCompositeData.stackTrace(ThreadInfoCompositeData.java:317)
at java.lang.management.ThreadInfo.<init>(ThreadInfo.java:277)
at java.lang.management.ThreadInfo.from(ThreadInfo.java:794)

and if I do thread dump of the same profiled application via Attach API, I see this:

"Intro" #26 prio=1 os_prio=31 tid=0x00007f949bc10800 nid=0xe41f waiting on condition [0x000000012bec8000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at java2d.Intro$Surface.null (Redefined)
at java.lang.Thread.null (Redefined)

note the "null" at the place of the method name. This corresponds to the NPE from JMX. All this leads me to the JDK-8025238, which introduced the "null (Redefined)" in the stack trace. It looks like there are some changes in handling method_id of redefined methods, since the above problems are new in JDK 8. JDK 7u72 works fine. JDK-8025238, fixed the problem for stack trace taken via Attach API, but JMX code is broken - it does not count with the fact that method name can be null. There is one very interesing thing - if you take a heap dump in the situation, when JXM thread dump fails with NPE and thread dump taken via Attach API displays "Thread.null (Redefined)", the stack traces stored in the heap dump have correct method names. So there is a way to do it right without "null" names. As a proof of concept, I am attaching the patch against JDK8u-dev, which fixes NPE in JMX thread dump and also avoids "null" method names in Attach API thread dump. This patch does not use method_id returned by method->method_idnum(). It looks like conversion to method_id and back to Method* does not work correctly for old redefined methods, which are still on the stack. Note that attached patch does not solve similar problem in java_lang_Throwable::get_stack_trace_element(), which should also updated to use MethodHandle instead of method_id.