OOM counters
Baesken, Matthias
matthias.baesken at sap.com
Fri Sep 21 15:19:19 UTC 2018
>
> 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>
More information about the serviceability-dev
mailing list