ResourceExhausted JVMTI event and -XX:*OnOutOfMemoryError

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

ResourceExhausted JVMTI event and -XX:*OnOutOfMemoryError

Yasumasa Suenaga-4
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.


Thanks,

Yasumasa
Reply | Threaded
Open this post in threaded view
|

Re: ResourceExhausted JVMTI event and -XX:*OnOutOfMemoryError

David Holmes
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
Reply | Threaded
Open this post in threaded view
|

Re: ResourceExhausted JVMTI event and -XX:*OnOutOfMemoryError

Yasumasa Suenaga-4
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
Reply | Threaded
Open this post in threaded view
|

Re: ResourceExhausted JVMTI event and -XX:*OnOutOfMemoryError

Yasumasa Suenaga-4
In reply to this post by David Holmes
Sorry, the format is broken... I re-sent the email:


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
Reply | Threaded
Open this post in threaded view
|

Re: ResourceExhausted JVMTI event and -XX:*OnOutOfMemoryError

David Holmes
On 23/07/2019 6:16 pm, Yasumasa Suenaga wrote:
> Sorry, the format is broken... I re-sent the email:
>
>
> 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 

The JVMTI spec can't say anything about -XX:*OnOutOfMemoryError as they
are a hotspot implementation detail. If you use the -XX flag you get
whatever the hotspot implementation does. That may override normal
specified behaviour. For example, if you use -XX:+ExitOnOutOfMemoryError
you can't then complain that the VM never executes a catch block for
OutOfMemoryError because it exited first! It's the same for the event
processing - we're exiting before we reach that code.

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

But we don't know what the handler will do. Nor do we know why the -XX
flag was used, or even what it may do in some cases.

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

There is no logical argument there for obsoleting the ResourceExhausted
event.

I understand you want the event to be posted before the flag is
processed, but somebody else may want it exactly as it is - e.g. dumping
the heap before their event handler does some cleanup/recovery work.

And as I said the JVM TI spec knows nothing of this XX flag so cannot
say anything about it.

David
-----

>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: ResourceExhausted JVMTI event and -XX:*OnOutOfMemoryError

Daniel D. Daugherty
I agree with David's opinion here. Please do not make this change.

Dan


On 7/23/19 7:08 AM, David Holmes wrote:

> On 23/07/2019 6:16 pm, Yasumasa Suenaga wrote:
>> Sorry, the format is broken... I re-sent the email:
>>
>>
>> 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 
>
>
> The JVMTI spec can't say anything about -XX:*OnOutOfMemoryError as
> they are a hotspot implementation detail. If you use the -XX flag you
> get whatever the hotspot implementation does. That may override normal
> specified behaviour. For example, if you use
> -XX:+ExitOnOutOfMemoryError you can't then complain that the VM never
> executes a catch block for OutOfMemoryError because it exited first!
> It's the same for the event processing - we're exiting before we reach
> that code.
>
>> 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.
>
> But we don't know what the handler will do. Nor do we know why the -XX
> flag was used, or even what it may do in some cases.
>
>> 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.
>
> There is no logical argument there for obsoleting the
> ResourceExhausted event.
>
> I understand you want the event to be posted before the flag is
> processed, but somebody else may want it exactly as it is - e.g.
> dumping the heap before their event handler does some cleanup/recovery
> work.
>
> And as I said the JVM TI spec knows nothing of this XX flag so cannot
> say anything about it.
>
> David
> -----
>
>>
>> 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

Reply | Threaded
Open this post in threaded view
|

Re: ResourceExhausted JVMTI event and -XX:*OnOutOfMemoryError

Yasumasa Suenaga-4
Hi David, Dan,

Thank you for explanation.
I will not file this to JBS.


Yasumasa


On 2019/07/23 22:57, Daniel D. Daugherty wrote:

> I agree with David's opinion here. Please do not make this change.
>
> Dan
>
>
> On 7/23/19 7:08 AM, David Holmes wrote:
>> On 23/07/2019 6:16 pm, Yasumasa Suenaga wrote:
>>> Sorry, the format is broken... I re-sent the email:
>>>
>>>
>>> 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 
>>
>>
>> The JVMTI spec can't say anything about -XX:*OnOutOfMemoryError as they are a hotspot implementation detail. If you use the -XX flag you get whatever the hotspot implementation does. That may override normal specified behaviour. For example, if you use -XX:+ExitOnOutOfMemoryError you can't then complain that the VM never executes a catch block for OutOfMemoryError because it exited first! It's the same for the event processing - we're exiting before we reach that code.
>>
>>> 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.
>>
>> But we don't know what the handler will do. Nor do we know why the -XX flag was used, or even what it may do in some cases.
>>
>>> 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.
>>
>> There is no logical argument there for obsoleting the ResourceExhausted event.
>>
>> I understand you want the event to be posted before the flag is processed, but somebody else may want it exactly as it is - e.g. dumping the heap before their event handler does some cleanup/recovery work.
>>
>> And as I said the JVM TI spec knows nothing of this XX flag so cannot say anything about it.
>>
>> David
>> -----
>>
>>>
>>> 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
>