This was brought up in the review thread for JDK-8212206, see https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-December/024310.html

Summary
-------
Rename hsperfdata counter `sun.gc.policy.gcTimeLimitExceeded` to `sun.gc.policy.gcOverheadLimitExceeded` and change its runtime behavior from a boolean value to a cumulative counter.

Problem
-------
The name `gcTimeLimitExceeded` is a misnomer, as its implementation takes into account both GC time limit and space limit. The counter currently holds a boolean value that is updated at every garbage collection, making it difficult for monitoring tools to catch the moment when it is set to `true`, as the next collection could reset it to `false` before the monitoring tools read the counter.

Solution
--------
Rename the counter to `sun.gc.policy.gcOverheadLimitExceeded`, and change its runtime behavior to a cumulative integer, which denotes the total number of collections that have triggered the "GC overhead limit exceeded" event. In this way monitoring tools can periodically poll the counter, without worrying about missing any update to the counter. When a Java process OOMs and terminates due to "GC overhead limit exceeded", the counter is guaranteed to hold a non-zero value.

Specification
-------------
`sun.gc.policy.gcTimeLimitExceeded` will be removed.
`sun.gc.policy.gcOverheadLimitExceeded` will be added, denoting the total number of collections that have triggered the "GC overhead limit exceeded" event.