On Fri, 15 Apr 2022 09:05:23 GMT, Thomas Stuefe <stu...@openjdk.org> wrote:
> 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. I came to the same conclusion. Therefore I don't think that adding CrashProtection is worth the effort. > 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. ASGCT makes it possible to develop your own profiler. The implementation overlaps but the feature set does not. You cannot build your own profiler with JFR. AsyncProfiler has with ASGCT the possibility to capture call traces with different intervals that are related to perf-events which is not possible in JFR. ASGCT should be a best effort API that has its caveats, one of them being that it might crash the VM. I think the goal is to make ASGCT as safe as possible to use without altering the normal behaviour (and speed) of the VM. Calling the API should not alter anything on the heap or in any other data structures. This is also true for JFR and many stability fixes for ASGCT (like using SafeFetch in some places) should also benefit the stability of JFR. I therefore want to close this PR (and the related issue) and propose my "[Do not call JavaThread::thread_from_jni_environment](https://github.com/openjdk/jdk/pull/8225/commits/b16e85d2251ae8cf7433ff146ea209d094a37c8a)" commit in a new PR as adding PRs for all the errors I find in JFR and ASGCT seems to be the way forward. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225
