On Sat, 16 Apr 2022 05:56:51 GMT, Thomas Stuefe <stu...@openjdk.org> wrote:
> I disagree on this one, partly because you a crash is not the worst that > could happen, that would be data corruption due to some freakish causal chain. Of course, but it is in reality far harder to test for. But ideally, ASGCT does never use a method that does alter state, at the expense that it might sometimes discard results. Even methods that modify caches (or comparable data structures) are problematic. I want to do a manual code analysis in the next few weeks of all code called by ASGCT (not just the parts that differ from JFR) to check whether this is true. > And partly because that crashiness of AGCT is little known outside our > community, so customers are probably not aware of this risk. I don't think so, the problem are more transitive users that use a tool like AsyncProfiler that might crash their VM (or corrupt the data). > Sounds reasonable. I'm sorry for frustrating your efforts here. At least I learned something. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225
