OOM counters

[Baesken, Matthias]

>
> Sorry, when I said "we added" I meant "in our internal JDK at Google" :-); not the OpenJDK one. But basically, from what I can tell when I look at the code; when an OOM happens,
> we get a callback and do some book-keeping in native land before returning and letting the JVM close up shop.
>

HI JC,  that sounds interesting  and in case it is better than what we have at the moment in OpenJDK  , it is interesting for us too .

From my understanding we have already some kind of callbacks in the present OpenJDK  for handling the OOMs :

  *   the XX flags  ExitOnOutOfMemoryError  and   OnOutOfMemoryError=<command>     :   this is in the hotspot code ,  however  this is a bit limited because it limits you to exit, or call an external shell script/command  via fork
  *   JVMTI   (haven’t looked into the details, but I think you would need to code a JVM agent – not an option in some use cases)

The use case  our customers have and  you asked about is more or less like what you describe in your first scenario .
They  check  in some cycle  for OOM ,  then  do some tracing maybe cleanup and exit .
For  this ,  they can use the eventqueue  of our SAP-internal JDK .

Best regards, Matthias


From: JC Beyler <jcbeyler at google.com>
Sent: Freitag, 21. September 2018 16:59
To: Baesken, Matthias <matthias.baesken at sap.com>
Cc: David Holmes <david.holmes at oracle.com>; serviceability-dev at openjdk.java.net
Subject: Re: OOM counters

Sorry, when I said "we added" I meant "in our internal JDK at Google" :-); not the OpenJDK one. But basically, from what I can tell when I look at the code; when an OOM happens, we get a callback and do some book-keeping in native land before returning and letting the JVM close up shop.

I had plans of also finding out if there is interest in pushing this forward and upstream for the community so: anyone can chime in now and say: yes this would be interesting to have.

Note: I'm not saying this is better than what you have; I just don't fully comprehend your use-case. An API to inspect those counters seems weird to me: when would you actually use it to see the counters are not 0? The only two cases I can see is that you either:

- The OOM happened and you caught it via a catch, now you go and look at the counters in Java land before the JVM will close up shop and do something with that information; seems weird to be doing things at an OOM in Java land but why not :)
- The OOM happened, you caught it via a catch; but your setup is such that you can survive an OOM and thus logging why an OOM happened is interesting; as the jobs keep surviving OOMs, you can actually track why OOMs happened

But perhaps I'm missing something :), my knowledge and understanding of OOMs (and let us be honest of actual Java land) is fairly limited :-)
Jc


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20180921/f14c43ae/attachment-0001.html>