On Thu, 14 Apr 2022 15:19:17 GMT, Johannes Bechberger <d...@openjdk.java.net> wrote:
>> Move the AsyncGetCallTrace method implementation into a separate method and >> wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` >> like it is done in >> [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but >> not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to >> `ticks_unknown_state` (-7) to signal a state that cannot be properly >> handled. `ticks_unknown_state` is currently also used for signaling unknown >> thread states but this should not be a problem, as the semantic is the same. >> If `num_frames` already has an error code then this error code is not >> changed. This helps to distinguish between errors in walking threads in Java >> and non-Java mode, as `num_frames` is set there before the walking to the >> appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one > additional commit since the last revision: > > Use JavaThread::current_or_null For additional context, I should add that the CrashProtection mechanism was mainly put in place as a result of having to deliver JFR from JRockit into Hotspot under a deadline. upholding feature-parity. The stack walking code was in really bad shape back then. Over the years though, it has been hardened and improved much, and I have not seen any reported issues about JFR crashes in many years (we log when crashing in production). An important difference is that AGCT allows more thread states compared to JFR, so there can be issues in that area that are not seen in JFR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225
