OOM counters

Baesken, Matthias matthias.baesken at sap.com
Wed Sep 19 16:01:03 UTC 2018


Hi JC, yes it is good to have for monitoring.

However  another application we have  is  that  people wanted to trigger actions on an OOM occurrence , like doing some restarts etc .

For these kind of actions  they had in  our proprietary JVM   some kind  of queue  containing  the latest “prominent”  errors (OOMs  , but also some others).
So they  periodically checked the queue  and  in case an OOM is found , they started  the desired action .

There is (to some extend)  a replacement for this in the VM,  the XX flags  ExitOnOutOfMemoryError  and   OnOutOfMemoryError=<command>   .
However,  these flags are not very flexible  (always exiting is not what all people want),   and  executing a command  forks and execs  a shell (see vmError)  which is quite some overhead
and  also a bit problematic in some cases.



Best regards, Matthias



From: JC Beyler <jcbeyler at google.com>
Sent: Mittwoch, 19. September 2018 16:49
To: Baesken, Matthias <matthias.baesken at sap.com>
Cc: hotspot-dev Source Developers <hotspot-dev at openjdk.java.net>; serviceability-dev at openjdk.java.net
Subject: Re: OOM counters

Hi Matthias,

In the case of an OOM, what's the use-case here? Are there cases where you are recuperating often from OOMs that the counters have different values and it's interesting to monitor? Or is it to determine which of the three got incremented by the OOM that was thrown?

Finally, when would you call the MemoryMXBean new call: if you are recuperating from OOMs, I could imagine that you might be able to get the counters periodically and monitor this; if you're not, you'd be doing this call during an OOM?

Thanks,
Jc

On Wed, Sep 19, 2018 at 2:13 AM Baesken, Matthias <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>> wrote:
Hello,  Currently we have already counters in the Hotspot codebase counting Java heap,
Metaspace and class metaspace related OOMs.

See declarations:

jdk/src/hotspot/share/utilities/exceptions.hpp


107  // Count out of memory errors that are interesting in error diagnosis
108  static volatile int _out_of_memory_error_java_heap_errors;
109  static volatile int _out_of_memory_error_metaspace_errors;
110  static volatile int _out_of_memory_error_class_metaspace_errors;

output :

jdk/src/hotspot/share/utilities/exceptions.cpp

460void Exceptions::print_exception_counts_on_error(outputStream* st) {
461  print_oom_count(st, "java_heap_errors", _out_of_memory_error_java_heap_errors);
462  print_oom_count(st, "metaspace_errors", _out_of_memory_error_metaspace_errors);
463  print_oom_count(st, "class_metaspace_errors", _out_of_memory_error_class_metaspace_errors);
464  if (_stack_overflow_errors > 0) {
465    st->print_cr("StackOverflowErrors=%d", _stack_overflow_errors);
466  }
467  if (_linkage_errors > 0) {
468    st->print_cr("LinkageErrors=%d", _linkage_errors);
469  }
470}


But currently  the output is  only done from vmError.cpp , in case of
a)  error reporting
b)  jcmd  vm.info<http://vm.info>  (in case exceptions happened, otherwise the section is not printed)

(see void VMError::print_vm_info(outputStream* st) { ... } )


It would be interesting for us to get the values of the existing counters via JDK coding.
In our proprietary JVM we had a similar mechanism.

Is there anything planned for this (or even already something present) ?

There exists already a class java/lang/management/MemoryMXBean.java  with a  management interface for the memory system of
the Java virtual machine.  It contains some "getter" - methods like

    public int getObjectPendingFinalizationCount();
    public MemoryUsage getHeapMemoryUsage();

Do you think we could add a method (or methods) for accessing the existing OOM counters
( for example,  public OomCounters getOutOfMemoryCounters();  ) ?


Best regards, Matthias


--

Thanks,
Jc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20180919/b464f163/attachment-0001.html>


More information about the serviceability-dev mailing list