The only advantage is that the stack-walking at safepoints is slightly less error-prone, as there are fewer mutations of heap and stack. A profiler that only profiles at a safepoint have an inherent bias because it only includes frames from the locations inside methods where Threads check for a safepoint.
Threads are regularly checking whether they should get into a safepoint, for example, at method entry, exit, or loop backjumps.
The JVM itself needs safepoints to do major garbage collections, Class definitions, method deoptimizations, and more. This is a noble effort, but it requires lots C/C++/Unix programming which is finicky, and not everyone can read C/C++ code.įor people unfamiliar with safepoint bias: A safepoint is a point in time where the JVM has a known defined state, and all threads have stopped. The only problem with this project: I wanted to write a proper non-safepoint-biased profiler from scratch. A few months back, I started writing a profiler from scratch, and the code since became the base of my profiler validation tools.
0 kommentar(er)
