[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: ResourceExhausted JVMTI event and -XX:*OnOutOfMemoryError
From:       Yasumasa Suenaga <yasuenag () gmail ! com>
Date:       2019-07-24 0:43:34
Message-ID: 9760936a-1008-1fe5-35bc-72a83591d318 () gmail ! com
[Download RAW message or body]

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
> 


[prev in list] [next in list] [prev in thread] [next in thread]