P4
As mentioned here:
http://mail.openjdk.java.net/pipermail/jmh-dev/2015-April/001800.html
http://mail.openjdk.java.net/pipermail/jmh-dev/2015-April/001820.html
...current profiler bindings capture more things than users reasonably expect.
Both internal and external profilers capture the infrastructure code, and at this point we "just" rely on benchmark code to completely dominate the execution. It would seem prudent to reconsider how profilers bind to the generated code. For example, triggering the internal profilers in the generated code itself would be nice. External profilers may also enjoy the notification/trigger that we have reached the measurement window.
http://mail.openjdk.java.net/pipermail/jmh-dev/2015-April/001800.html
http://mail.openjdk.java.net/pipermail/jmh-dev/2015-April/001820.html
...current profiler bindings capture more things than users reasonably expect.
Both internal and external profilers capture the infrastructure code, and at this point we "just" rely on benchmark code to completely dominate the execution. It would seem prudent to reconsider how profilers bind to the generated code. For example, triggering the internal profilers in the generated code itself would be nice. External profilers may also enjoy the notification/trigger that we have reached the measurement window.