Add the micro-benchmark for thread filtering#237
Merged
Conversation
| @Param({"0", "7", "70000"}) | ||
| public String workload; | ||
|
|
||
| private long workloadNum = 0; |
There was a problem hiding this comment.
🟠 Code Quality Violation
Suggested change
| 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.
Contributor
Contributor
|
🔧 Report generated by pr-comment-scanbuild |
zhengyu123
pushed a commit
that referenced
this pull request
Jul 9, 2025
* Add the micro-benchmark for thread filtering * Do not test for obviously invalid thread id * Relax threadfilter mem order
zhengyu123
added a commit
that referenced
this pull request
Jul 9, 2025
* 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 <zhengyu.gu@servicenow.com> Co-authored-by: Datadog Java Profiler <java-profiler@datadoghq.com> Co-authored-by: Jaroslav Bachorik <jaroslav.bachorik@datadoghq.com> Co-authored-by: Jaroslav Bachorik <j.bachorik@gmail.com> Co-authored-by: r1viollet <74836499+r1viollet@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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!