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 in
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 “promine
Hi Jc,
Updated tests looks good.
Some notes about implementation.
- FatalOnException implements both verification and error handling
It would be better to separate them (and this makes easy to implement
error handling different from JNIEnv::FatalError).
The simplest way is to define error hand
Hi Jc,
Looks good to me.
A minor note:
- I'd move ErrorHandler typedef to SafeJNIEnv class to avoid global
namespece pollution (ErrorHandler is too generic name).
--alex
On 09/19/2018 15:56, JC Beyler wrote:
Hi Alex,
I've updated the webrev to:
Webrev: http://cr.openjdk.java.net/~jcbeyler/8
Hi all,
Ping.
The bug has been labeled "timewaster" as it caused failures quite often.
--alex
On 09/17/2018 12:57, Alex Menkov wrote:
Hi Gary,
updated webrev:
http://cr.openjdk.java.net/~amenkov/sh2java/timeout/webrev.02/
see comments inline.
On 09/17/2018 11:57, Gary Adams wrote:
Should s
Hi Matthias,
Those counters, as I recall, were added to the hs_err report purely to
show if an application/test had been "playing too close to the edge"
before it crashed. They were never intended as user-inspectable values.
I have no opinion as to whether they should be.
David
On 19/09/20
Hi David , the values are already user-inspectable via jcmd vm.info ,
however this way is not very user friendly (and I am not sure how stable it is
between updates / releases).
Probably not as stable as an API .
Best regards, Matthias
> -Original Message-
> From: David Holmes
