On Thu, 14 Apr 2022 17:08:32 GMT, Markus Grönlund <mgron...@openjdk.org> wrote:
> 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, 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. Thanks for the JFR insight, Marcus. I can see the CrashProtection being a stop-gap measure under time constraints. Maybe worth rethinking now. From your description, the way it is used in JFR differ significantly from how the async-profiler would use it. Privately, I start wondering whether the benefits of async-profiler over JFR are worth the risk of corrupting the VM or the work needed to harden out AGCT. Their feature-set seems to overlap a lot. I may not see the whole picture though, I'm not a profiler expert. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225
