-
Notifications
You must be signed in to change notification settings - Fork 10
[PROF-12714] Add CriticalNative support #282
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
base: main
Are you sure you want to change the base?
Conversation
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.
Hey 👋 . As requested, I gave it a stab at reviewing the PR!
I'm missing some context on this code, in particular it was hard to determine which methods were performance-critical and which were used only for setup/testing/etc off the critical path.
I wonder if it's worth documenting and/or reflecting that in the method names.
I saw the benchmarks in JIRA -- I guess the important part is that ThreadFilterBenchmark is faster? May be worth posting them here too, to give a bit more context.
ddprof-lib/src/main/cpp/javaApi.cpp
Outdated
| extern "C" DLLEXPORT jlong JNICALL | ||
| Java_com_datadoghq_profiler_JavaProfiler_tscFrequency0(JNIEnv *env, | ||
| jobject unused) { | ||
| jclass unused) { | ||
| return TSC::frequency(); | ||
| } | ||
|
|
||
| extern "C" DLLEXPORT jlong JNICALL | ||
| JavaCritical_com_datadoghq_profiler_JavaProfiler_tscFrequency0() { |
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.
Similar note to init0 -- this value seems to be saved in a static final on the Java side and never called again.
|
Hmm... I'll be honest and say that I don't think this is the way to go. Specifically:
Can I maybe convince you to revisit your approach here? 😄 😉 👀 |
I am bit confused by your comments - Are you suggesting not to introduce |
The latter, indeed: I am suggesting to remove the non-performance critical. TL;DR version of my point is: I think the trade-off is worth it 👍 for the ones that give us performance, but not worth it for the ones that don't 👎 . |
Benchmarks [x86_64 wall]Parameters
See matching parameters
SummaryFound 0 performance improvements and 0 performance regressions! Performance is the same for 15 metrics, 23 unstable metrics. |
Benchmarks [x86_64 alloc]Parameters
See matching parameters
SummaryFound 0 performance improvements and 1 performance regressions! Performance is the same for 14 metrics, 23 unstable metrics.
|
Benchmarks [x86_64 cpu]Parameters
See matching parameters
SummaryFound 0 performance improvements and 0 performance regressions! Performance is the same for 15 metrics, 23 unstable metrics. |
Benchmarks [x86_64 cpu,wall,alloc,memleak]Parameters
See matching parameters
SummaryFound 0 performance improvements and 0 performance regressions! Performance is the same for 15 metrics, 23 unstable metrics. |
Benchmarks [x86_64 memleak]Parameters
See matching parameters
SummaryFound 0 performance improvements and 0 performance regressions! Performance is the same for 16 metrics, 22 unstable metrics. |
Benchmarks [aarch64 cpu]Parameters
See matching parameters
SummaryFound 0 performance improvements and 0 performance regressions! Performance is the same for 17 metrics, 21 unstable metrics. |
Benchmarks [x86_64 memleak,alloc]Parameters
See matching parameters
SummaryFound 0 performance improvements and 0 performance regressions! Performance is the same for 14 metrics, 24 unstable metrics. |
Benchmarks [x86_64 cpu,wall]Parameters
See matching parameters
SummaryFound 0 performance improvements and 0 performance regressions! Performance is the same for 14 metrics, 24 unstable metrics. |
Benchmarks [aarch64 memleak]Parameters
See matching parameters
SummaryFound 0 performance improvements and 0 performance regressions! Performance is the same for 17 metrics, 21 unstable metrics. |
Benchmarks [aarch64 wall]Parameters
See matching parameters
SummaryFound 0 performance improvements and 0 performance regressions! Performance is the same for 16 metrics, 22 unstable metrics. |
Benchmarks [aarch64 alloc]Parameters
See matching parameters
SummaryFound 0 performance improvements and 0 performance regressions! Performance is the same for 17 metrics, 21 unstable metrics. |
Benchmarks [aarch64 cpu,wall,alloc,memleak]Parameters
See matching parameters
SummaryFound 0 performance improvements and 0 performance regressions! Performance is the same for 17 metrics, 21 unstable metrics. |
Benchmarks [aarch64 cpu,wall]Parameters
See matching parameters
SummaryFound 0 performance improvements and 0 performance regressions! Performance is the same for 16 metrics, 22 unstable metrics. |
Benchmarks [aarch64 memleak,alloc]Parameters
See matching parameters
SummaryFound 0 performance improvements and 0 performance regressions! Performance is the same for 16 metrics, 22 unstable metrics. |
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.
👍 Looks reasonable! I'd still strongly recommend being a lot more explicit about the ARM64 workaround code, so it's extremely clear for future maintainers why it exists (and when we can get rid of it)
| extern "C" DLLEXPORT void JNICALL | ||
| Java_com_datadoghq_profiler_JavaProfiler_filterThreadAdd0(JNIEnv *env, | ||
| jobject unused) { | ||
| JavaCritical_com_datadoghq_profiler_JavaProfiler_filterThreadAdd0() { |
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.
Minor: Should we maybe declare these as inline to softly suggest to the compiler that Java_com_datadoghq_profiler_JavaProfiler_filterThreadAdd0 should inline this, not call into it?
(Or does that not work very well anyway?)
| void VMStructs_::initCriticalJNINatives() { | ||
| #ifdef __aarch64__ | ||
| // aarch64 does not support CriticalJNINatives | ||
| JVMFlag* flag = JVMFlag::find("CriticalJNINatives", {JVMFlag::Type::Bool}); | ||
| if (flag != nullptr && flag->get()) { | ||
| flag->set(0); | ||
| } | ||
| #endif // __aarch64__ | ||
| } | ||
|
|
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.
I still think we should have better documentation here of:
- Why is this needed (work around JDK 8 bug on ... )
- What happens if this is not here
"// aarch64 does not support CriticalJNINatives" I'm not sure will be enough for someone 1/2/n years from now to understand why this was added.
Bonus points for reflecting this into the method name e.g. installWorkaroundForJdk8ArmCrash (or something similarly descriptive) would be a good way of conveying some of this information :)
What does this PR do?:
Motivation:
Additional Notes:
How to test the change?:
For Datadog employees:
credentials of any kind, I've requested a review from
@DataDog/security-design-and-guidance.Unsure? Have a question? Request a review!