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)
