-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve the overall fidelity of JFR profiles and reduce sampling bias #1376
base: develop
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,16 @@ | ||
type: improvement | ||
improvement: | ||
description: |- | ||
Improve the overall fidelity of JFR profiles and reduce safepoint sampling bias | ||
|
||
Note due to https://bugs.openjdk.org/browse/JDK-8201516 there may still | ||
be potentially small incorrect attribution, but overall this tradeoff is | ||
worth the sampling bias impact. | ||
|
||
See references: | ||
* http://hirt.se/blog/?p=609 | ||
* https://docs.oracle.com/javacomponents/jmc-5-5/jfr-runtime-guide/about.htm#JFRRT111 | ||
* https://psy-lob-saw.blogspot.com/2016/02/why-most-sampling-java-profilers-are.html | ||
* https://jpbempel.github.io/2022/06/22/debug-non-safepoints.html | ||
links: | ||
- https://github.com/palantir/sls-packaging/pull/1376 |
Original file line number | Diff line number | Diff line change | ||||||
---|---|---|---|---|---|---|---|---|
|
@@ -74,6 +74,11 @@ public abstract class LaunchConfigTask extends DefaultTask { | |||||||
// AWS-managed systems that modify DNS records on failover. | ||||||||
"-Dsun.net.inetaddr.ttl=20", | ||||||||
"-XX:NativeMemoryTracking=summary", | ||||||||
// Improve the overall fidelity of JFR profiles and reduce sampling bias, | ||||||||
// see http://hirt.se/blog/?p=609 & https://jpbempel.github.io/2022/06/22/debug-non-safepoints.html | ||||||||
// Per https://bugs.openjdk.org/browse/JDK-8201516 may still be potentially incorrect attribution. | ||||||||
"-XX:+UnlockDiagnosticVMOptions", | ||||||||
"-XX:+DebugNonSafepoints", | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Consider testing impact of preserving frame pointers for native and kernel traces, though that may be too expensive to enable by default:
Suggested change
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I haven't had a chance to benchmark myself, do you know if there's a measurable runtime cost associated with There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I haven't had cycles yet to benchmark with/without Async-profiler enables DebugNonSafepoints via JVMTI agent registering CompileMethodLoad Also worth reading the note http://hirt.se/blog/?p=609 from Marcus Hirt, one of the original JRockit and JFR authors. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Benchmarks don't appear to be impacted (results are within margin of error) |
||||||||
// Increase default JFR stack depth beyond the default (conservative) 64 frames. | ||||||||
// This can be overridden by user-provided options. | ||||||||
// See sls-packaging#1230 | ||||||||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some danger opting into this by default: jvm option overrides may rely upon this without realizing, meaning it cannot safely be removed from sls-packaging. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, adding this now would make removing any diagnostic VM arg that depends on it a break. We could mitigate a bit with
-XX:+IgnoreUnrecognizedVMOptions
where startup would no longer fail on those args, but we could silently end up in a situation where we assume args are in effect when they're not actually.