Call stack:
Current thread (0x00007ff0b9322000): JavaThread "DestroyJavaVM" [_thread_in_vm, id=8195, stack(0x000000010c017000,0x000000010c117000)]

Stack: [0x000000010c017000,0x000000010c117000], sp=0x000000010c1168e0, free space=1022k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.dylib+0xa8b8d2] MethodArityHistogram::add_method_to_histogram(nmethod*)+0x20
V [libjvm.dylib+0x385b57] CodeCache::nmethods_do(void (*)(nmethod*))+0x41
V [libjvm.dylib+0xa8b855] MethodArityHistogram::MethodArityHistogram()+0x5d
V [libjvm.dylib+0xa88c76] SharedRuntime::print_call_statistics(int)+0x38c
V [libjvm.dylib+0x62c499] print_method_invocation_histogram()+0x3ba
V [libjvm.dylib+0x62c6ae] print_statistics()+0x19c
V [libjvm.dylib+0x62ccca] before_exit(JavaThread*)+0x35e
V [libjvm.dylib+0xb54e2c] Threads::destroy_vm()+0xf6
V [libjvm.dylib+0x6d93f0] jni_DestroyJavaVM+0xd9
C [java+0x45a6] JavaMain+0xa14
C [libsystem_pthread.dylib+0x3661] _pthread_body+0x154
C [libsystem_pthread.dylib+0x350d] _pthread_body+0x0
C [libsystem_pthread.dylib+0x2bf9] thread_start+0xd

CodeCache::nmethods_do() iterates over all existing methods. Among those might be some which are not fully constructed yet. Thus, the _method field might be zero or (even worse) contain a random value. This effect was observed previously while implementing CodeHeap State Analytics.

I would expect this bug to exist in previous versions as well.