Re: RFR (M) 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value"

[serguei.spit...@oracle.com]

On 12/4/19 14:15, serguei.spit...@oracle.com wrote: Hi Collen, Sorry, I typed your name incorrectly. Thanks, Serguei It looks good in general. Thank you a lot for sorting this out! Just a couple of comments. http://cr.openjdk.java.net/~coleenp/2019/8212160.01/webrev/src/hotspot/share/runtime/thread.hpp.frames.html 1993 protected: 1994 // Jvmti Events that cannot be posted in their current context. 1995 // ServiceThread uses this to collect deferred events from NonJava threads 1996 // that cannot post events. 1997 JvmtiDeferredEventQueue* _jvmti_event_queue; As David I also have a concern about footprint of having the _jvmti_event_queue field in the Thread class. I'm thinking if it'd be better to move this field into the JvmtiThreadState class. Please, see jvmti_thread_state() and JvmtiThreadState::state_for(JavaThread *thread). http://cr.openjdk.java.net/~coleenp/2019/8212160.01/webrev/src/hotspot/share/prims/jvmtiImpl.cpp.frames.html 973 void JvmtiDeferredEvent::post(JvmtiEnv* env) { 974 assert(_type == TYPE_COMPILED_METHOD_LOAD, "only user of this method"); 975 nmethod* nm = _event_data.compiled_method_load; 976 JvmtiExport::post_compiled_method_load(env, nm); 977 } The JvmtiDeferredEvent::post name looks too generic as it posts compiled load events only. Do you consider this function extended in the future to support more event types? Thanks, Serguei   On 11/26/19 06:22, coleen.phillim...@oracle.com wrote: Summary: Add local deferred event list to thread to post events outside CodeCache_lock. This patch builds on the patch for JDK-8173361.  With this patch, I made the JvmtiDeferredEventQueue an instance class (not AllStatic) and have one per thread.  The CodeBlob event that used to drop the CodeCache_lock and raced with the sweeper thread, adds the events it wants to post to its thread local list, and processes it outside the lock.  The list is walked in GC and by the sweeper to keep the nmethods from being unloaded and zombied, respectively. Also, the jmethod_id field in nmethod was only used as a boolean so don't create a jmethod_id until needed for post_compiled_method_unload. Ran hs tier1-8 on linux-x64-debug and the stress test that crashed in the original bug report. open webrev at http://cr.openjdk.java.net/~coleenp/2019/8212160.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8212160 Thanks, Coleen