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

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Mon Dec 2 14:43:38 UTC 2019



On 11/26/19 7:03 PM, David Holmes wrote:
> (adding runtime as well)
>
> Hi Coleen,
>
> On 27/11/2019 12:22 am, coleen.phillimore at 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.
>
> Sorry I don't understand why we would want/need a deferred event queue 
> for every JavaThread? Isn't this only relevant for non-JavaThreads 
> that need to have the ServiceThread process the deferred event?

I thought I'd written this in the bug but I had only discussed this with 
Erik.  I've added a comment to the bug to explain why I added the 
per-JavaThread queue.  In order to process these events after the 
CodeCache_lock is dropped, I have to queue them somewhere safe. The 
ServiceThread queue is safe, *but* the ServiceThread can't keep up with 
the events, especially from this test case.  So the test case gets a 
native OOM.

So I've added the safe queue as a field to each JavaThread because 
multiple JavaThreads could be posting these events at the same time, and 
there didn't seem to be a better safe place to cache them, without 
adding another layer of queuing code.

I did write comments to this effect here:

http://cr.openjdk.java.net/~coleenp/2019/8212160.01/webrev/src/hotspot/share/prims/jvmtiCodeBlobEvents.cpp.udiff.html

Thanks,
Coleen

>
> David
>
>> 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



More information about the serviceability-dev mailing list