GetStackTrace is the only official API to obtain stack traces but it has precision problems. The only difference is that AsyncGetCallTrace (ASGCT) returns the stack trace at any point in the execution of the program and GetStackTrace (GST) only at specific safe points, where the state of the JVM is defined. AsyncGetCallTrace and GetStackTraceĪ short recap from my series "Writing a Profiler from Scratch" - both APIs return the stack trace for a given thread at a given point in time (A called B, which in turn called C. I hope to be on schedule again next week.
The tool took far longer to bring to a usable(ish) state this is why I didn't write an article last week. I focus here on the AsyncGetCallTrace and GetStackTrace API, but due to the similarity in the code, JFR should have similar correctness properties. In this article, we will cover a new prototypical tool called trace_validation and its foundational concepts. Such tools are invaluable when modifying the API implementation or adding a new API. I already wrote code to test the stability of the profiling APIs, testing for the lack of fatal errors, in my jdk-profiling-tester project. Potentially uncovering more bugs or being more confident in the absence of errors. Now the question is: could we find such bugs automatically? In my last article, I covered a correctness bug in the fundamental Java profiling API AsyncGetCallTrace that I found just by chance. JEP Candidate 435, in the SapMachine team at SAP. A JVM developer working on profilers and their underlying technology, e.g.
0 kommentar(er)
