What actions are allowed in an JVMTI ResourceExhausted event handler?

Chris Plummer chris.plummer at oracle.com
Wed Nov 14 05:37:05 UTC 2018


On 11/13/18 9:32 PM, David Holmes wrote:
> Hi Thomas,
>
> On 14/11/2018 6:50 am, Thomas Stüfe wrote:
>> Hi all,
>>
>> We have a client using CloudFoundry and its "jvmkill" agent. That is a
>> tiny JVMTI agent (see https://github.com/cloudfoundry/jvmkill) which
>> subscribes to the JVMTI ResourceExhausted Event. In the handler it
>> then does call JVMTI FollowReferences() to produce a heap histogram.
>>
>> The thing is, at our client we seem to run out of Metaspace in a
>> compiler thread. That thread normally would swallow the Metaspace OOM
>> and just bailout from the compilation. But as part of the metaspace
>> OOME handling the ResourceExhausted event gets posted, the handler
>> then uses JVMTI FollowReferences() and attempts to print out the heap
>> histogram, then runs into a guarantee since the compiler thread cannot
>> call java methods.
>>
>> My question is: are there any limitations about what one can do inside
>> a ResourceExhausted event handler?
>
> Not specified no. But the reality of JVM TI is that you can't 
> anticipate every execution context and there are times when there are 
> implicit constraints imposed by the implementation.
>
> In this case I think we have a mismatch between the fact we post the 
> event from the compiler thread, but that a compiler thread is not a 
> true "Java thread" and so can not execute arbitrary JNI or JVM TI 
> code, or in particular can not lead to executing Java code. I think we 
> should not be posting the event from the compiler thread in this case.
>
Does the recent fix for https://bugs.openjdk.java.net/browse/JDK-8193126 
address the metaspace failure you are seeing?

Chris
> Cheers,
> David
>
>> I checked the 
>> https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html
>> documentation, but I cannot find any mentioning of limitations in that
>> case.
>>
>> Thanks and Best Regards, Thomas
>>




More information about the serviceability-dev mailing list