ResourceExhausted JVMTI event and -XX:*OnOutOfMemoryError

Yasumasa Suenaga yasuenag at gmail.com
Tue Jul 23 08:13:18 UTC 2019


Hi David,                                                                                                                                                                                                                                       There are not documented the relation between -XX:*OnOutOfMemoryError and ResourceExhausted, but JVMTI spec says ResourceExhausted is sent when VM resource are exhausted.

https://docs.oracle.com/en/java/javase/12/docs/specs/jvmti.html#ResourceExhausted

As you said, we should not do other things when OutOfMemoryError is occurred. But I think it should be compliant when we will use Java related code in the event handler. If we do with C/C++ only (e.g. call printf()), I think we can do that.

If all codes should not be run when OutOfMemoryError is occurred, ResourceExhausted should be obsoleted, or we need to add the note for JVMTI document.


Thanks,

Yasumasa


On 2019/07/23 16:43, David Holmes wrote:
> Hi Yasumasa,
> 
> On 23/07/2019 5:24 pm, Yasumasa Suenaga wrote:
>> Hi all,
>>
>> I tried to use JVMTI agent which hooks ResourceExhausted event and -XX:ExitOnOutOfMemoryError together.
>> The process was exited when OutOfMemoryError was occurred, but ResourceExhausted event was not fired.
>>
>> I checked HotSpot implementation, -XX:*OutOfMemoryError is processed before JVMTI event processing.
>>
>> http://hg.openjdk.java.net/jdk/jdk/file/d999a1a11485/src/hotspot/share/gc/shared/memAllocator.cpp#l125
>>
>> IMHO ResourceExhausted should be called before -XX:*OutOfMemoryError.
>> If it is a bug, I will file it to JBS and fix it.
> 
> I don't think it is a bug. First, there's no specification for how these two things interact - -XX:*OnOutOfMemoryError is just a VM specific debugging/diagnostic hook. Second, if we're out of memory then we don't want to be doing other things which may need to also acquire memory. Third, no matter which way you code this someone may in some case want it the other way - and it's not worth coding to allow such flexibility IMO.
> 
> Just my $2. :)
> 
> Cheers,
> David
> 
>>
>> Thanks,
>>
>> Yasumasa


More information about the serviceability-dev mailing list