RFR: 8326012: JFR: Event for safepoint timeout [v2]

[Denghui Dong]

> There are now some JFR events related to safepoint. When time-to-safepoint (aka ttsp) is too long, these events could not be very helpful since based on them we cannot know which threads cause it and what those threads are doing.
> 
> Users can use `-XX:+SafepointTimeout -XX:SafepointTimeoutDelay=100` to see the threads that don't reach safepoint in time but without stack traces. Using `-XX:+ AbortVMOnSafepointTimeout` can capture the stack traces but it crashes the process, hence it's not sensible to enable the flag in production.
> 
> This patch adds a new JFR event `EventSafepoint` to record the threads that cause ttsp too long.
> 
> This event includes two fields:
> 
> - safepointId: the relevant safepoint id
> - timeExceeded: the amount of time exceeding `SafepointTimeoutDelay` used by the thread to reach safepoint
> 
> In the current version, this event records the stack of those problematic threads when they finally reach safepoint. Hence, there is a bias, but it's still helpful to deduce the root place.
> 
> A better implementation is to record a more accurate stack, but this will increase complexity. At the same time, the native stack may also be important for this problem, but it is not currently supported by JFR.
> 
> Any input would be greatly appreciated.
> 
> Testing: jdk/jdk/jfr

Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:

  remove debug code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17888/files
  - new: https://git.openjdk.org/jdk/pull/17888/files/5f374898..1e831de7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17888&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17888&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17888.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17888/head:pull/17888

PR: https://git.openjdk.org/jdk/pull/17888