-
Notifications
You must be signed in to change notification settings - Fork 9
Add the micro-benchmark for thread filtering #237
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
Conversation
@Param({"0", "7", "70000"}) | ||
public String workload; | ||
|
||
private long workloadNum = 0; |
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.
🟠 Code Quality Violation
private long workloadNum = 0; | |
private long workloadNum; |
Remove initialization, this is already the default value. (...read more)
When initializing fields, prevent initializing fields to the default value. Any additional initialization means more bytecode instructions, and allocating many of these objects may impact your application performance.
If you initialize to a default value, remove the initialization.
🔧 Report generated by pr-comment-scanbuild |
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.
LGTM
* Add the micro-benchmark for thread filtering * Do not test for obviously invalid thread id * Relax threadfilter mem order
* Potential memory leak with the JVMTI wallclock sampler * v1 * Don't sample terminated thread * v2 * v3 * v4 * Safe access * Fix thread state * v5 * Cleanup * Cleanup * safeFetch impl * jdk11 support * v6 * enhance and cleanup * fix nullptr deference * More cleanup * Erwan's finding * Fixed memory leak found by Erwan * [Automated] Bump dev version to 1.29.0 * Update the sonatype repos (#235) * Fix artifact download URL * Split debug (#233) * Split debug Add build steps to store split debug information for release builds * Add the micro-benchmark for thread filtering (#237) * Add the micro-benchmark for thread filtering * Do not test for obviously invalid thread id * Relax threadfilter mem order * Flaky test - j9 OSR (#239) Skip zing and j9 flaky tests * Fix flaky allocation test (#241) Lower threshold for allocation test * jbachorik's comments * More jbachorik's comments * Cleanup thread local references --------- Co-authored-by: zhengyu.gu <[email protected]> Co-authored-by: Datadog Java Profiler <[email protected]> Co-authored-by: Jaroslav Bachorik <[email protected]> Co-authored-by: Jaroslav Bachorik <[email protected]> Co-authored-by: r1viollet <[email protected]>
What does this PR do?:
It adds the very limited micro-benchmark for ThreadFilter.addThread/removeThread combination
Motivation:
Reduce the noise in the more 'macro-benchmarky' benchmarks. Allow to focus on the sole performance of adding and removing a thread to the filter with specific parallelism and synthetic workload and see how the performance scales.
Additional Notes:
Running this benchmark on MacBook M1 the difference between the JNI access and Unsafe access is almost non-existent.
We see a huge cliff when going from single thread to more threads when the workload is very low (10-100ns) which seems to be caused by:
JNI access
Unsafe access
Unsure? Have a question? Request a review!