> > 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 <[email protected]> Sent: Freitag, 21. September 2018 16:59 To: Baesken, Matthias <[email protected]> Cc: David Holmes <[email protected]>; [email protected] 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
