Bail out if we're in a no-dynamic-code scenario #6362
Merged
Conversation
This file contains 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
andrewlock
added
area:tracer
tonyredondo
approved these changes
Nov 27, 2024
kevingosse
approved these changes
Nov 27, 2024
I believe we don't do any rewriting (other than the startup hook) until Datadog.Trace is loaded? Since we're preventing it from being loaded, it should be fine. |
is this true @daniel-romano-DD ? |
Datadog ReportBranch report: ✅ 0 Failed, 450418 Passed, 2749 Skipped, 19h 38m 57.06s Total Time |
Execution-Time Benchmarks Report ⏱️Execution-time results for samples comparing the following branches/commits: Execution-time benchmarks measure the whole time it takes to execute a program. And are intended to measure the one-off costs. Cases where the execution time results for the PR are worse than latest master results are shown in red. The following thresholds were used for comparing the execution times:
Note that these results are based on a single point-in-time result for each branch. For full results, see the dashboard. Graphs show the p99 interval based on the mean and StdDev of the test run, as well as the mean value of the run (shown as a diamond below the graph). gantt
title Execution time (ms) FakeDbCommand (.NET Framework 4.6.2)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6362) - mean (69ms) : 66, 72
. : milestone, 69,
master - mean (69ms) : 66, 72
. : milestone, 69,
section CallTarget+Inlining+NGEN
This PR (6362) - mean (980ms) : 953, 1007
. : milestone, 980,
master - mean (976ms) : 950, 1002
. : milestone, 976,
gantt
title Execution time (ms) FakeDbCommand (.NET Core 3.1)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6362) - mean (108ms) : 106, 110
. : milestone, 108,
master - mean (108ms) : 105, 111
. : milestone, 108,
section CallTarget+Inlining+NGEN
This PR (6362) - mean (678ms) : 663, 694
. : milestone, 678,
master - mean (678ms) : 664, 693
. : milestone, 678,
gantt
title Execution time (ms) FakeDbCommand (.NET 6)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6362) - mean (91ms) : 89, 93
. : milestone, 91,
master - mean (91ms) : 89, 93
. : milestone, 91,
section CallTarget+Inlining+NGEN
This PR (6362) - mean (626ms) : 610, 643
. : milestone, 626,
master - mean (632ms) : 617, 647
. : milestone, 632,
gantt
title Execution time (ms) HttpMessageHandler (.NET Framework 4.6.2)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6362) - mean (191ms) : 187, 196
. : milestone, 191,
master - mean (191ms) : 186, 196
. : milestone, 191,
section CallTarget+Inlining+NGEN
This PR (6362) - mean (1,099ms) : 1062, 1137
. : milestone, 1099,
master - mean (1,094ms) : 1062, 1126
. : milestone, 1094,
gantt
title Execution time (ms) HttpMessageHandler (.NET Core 3.1)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6362) - mean (278ms) : 274, 283
. : milestone, 278,
master - mean (275ms) : 270, 280
. : milestone, 275,
section CallTarget+Inlining+NGEN
This PR (6362) - mean (873ms) : 844, 901
. : milestone, 873,
master - mean (872ms) : 846, 898
. : milestone, 872,
gantt
title Execution time (ms) HttpMessageHandler (.NET 6)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6362) - mean (266ms) : 262, 270
. : milestone, 266,
master - mean (266ms) : 260, 271
. : milestone, 266,
section CallTarget+Inlining+NGEN
This PR (6362) - mean (846ms) : 812, 879
. : milestone, 846,
master - mean (850ms) : 816, 885
. : milestone, 850,
|
Benchmarks Report for tracer 🐌Benchmarks for #6362 compared to master:
The following thresholds were used for comparing the benchmark speeds:
Allocation changes below 0.5% are ignored. Benchmark detailsBenchmarks.Trace.ActivityBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.AgentWriterBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.AspNetCoreBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.CIVisibilityProtocolWriterBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.DbCommandBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.ElasticsearchBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.GraphQLBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.HttpClientBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.ILoggerBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.Log4netBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.NLogBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.RedisBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.SerilogBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.SpanBenchmark - Slower
|
| Benchmark | diff/base | Base Median (ns) | Diff Median (ns) | Modality |
|---|---|---|---|---|
| Benchmarks.Trace.SpanBenchmark.StartFinishSpan‑netcoreapp3.1 | 1.146 | 565.65 | 648.06 | |
| Benchmarks.Trace.SpanBenchmark.StartFinishSpan‑net6.0 | 1.113 | 407.73 | 453.90 |
Raw results
| Branch | Method | Toolchain | Mean | StdError | StdDev | Gen 0 | Gen 1 | Gen 2 | Allocated |
|---|---|---|---|---|---|---|---|---|---|
| master | StartFinishSpan |
net6.0 | 408ns | 0.135ns | 0.487ns | 0.00799 | 0 | 0 | 576 B |
| master | StartFinishSpan |
netcoreapp3.1 | 565ns | 1.49ns | 5.78ns | 0.00779 | 0 | 0 | 576 B |
| master | StartFinishSpan |
net472 | 676ns | 0.404ns | 1.56ns | 0.0915 | 0 | 0 | 578 B |
| master | StartFinishScope |
net6.0 | 487ns | 0.241ns | 0.934ns | 0.00965 | 0 | 0 | 696 B |
| master | StartFinishScope |
netcoreapp3.1 | 676ns | 0.274ns | 0.986ns | 0.00934 | 0 | 0 | 696 B |
| master | StartFinishScope |
net472 | 880ns | 0.46ns | 1.78ns | 0.104 | 0 | 0 | 658 B |
| #6362 | StartFinishSpan |
net6.0 | 454ns | 0.204ns | 0.765ns | 0.00803 | 0 | 0 | 576 B |
| #6362 | StartFinishSpan |
netcoreapp3.1 | 645ns | 2.1ns | 8.12ns | 0.0078 | 0 | 0 | 576 B |
| #6362 | StartFinishSpan |
net472 | 625ns | 0.478ns | 1.85ns | 0.0916 | 0 | 0 | 578 B |
| #6362 | StartFinishScope |
net6.0 | 485ns | 0.336ns | 1.3ns | 0.0097 | 0 | 0 | 696 B |
| #6362 | StartFinishScope |
netcoreapp3.1 | 742ns | 0.567ns | 2.19ns | 0.00941 | 0 | 0 | 696 B |
| #6362 | StartFinishScope |
net472 | 910ns | 0.395ns | 1.53ns | 0.105 | 0 | 0 | 658 B |
Benchmarks.Trace.TraceAnnotationsBenchmark - Same speed ✔️ Same allocations ✔️
Raw results
| Branch | Method | Toolchain | Mean | StdError | StdDev | Gen 0 | Gen 1 | Gen 2 | Allocated |
|---|---|---|---|---|---|---|---|---|---|
| master | RunOnMethodBegin |
net6.0 | 686ns | 0.519ns | 2.01ns | 0.00971 | 0 | 0 | 696 B |
| master | RunOnMethodBegin |
netcoreapp3.1 | 931ns | 1.24ns | 4.79ns | 0.00901 | 0 | 0 | 696 B |
| master | RunOnMethodBegin |
net472 | 1.13μs | 0.561ns | 2.17ns | 0.105 | 0 | 0 | 658 B |
| #6362 | RunOnMethodBegin |
net6.0 | 663ns | 0.214ns | 0.828ns | 0.00961 | 0 | 0 | 696 B |
| #6362 | RunOnMethodBegin |
netcoreapp3.1 | 934ns | 0.437ns | 1.63ns | 0.00938 | 0 | 0 | 696 B |
| #6362 | RunOnMethodBegin |
net472 | 1.09μs | 0.396ns | 1.53ns | 0.105 | 0 | 0 | 658 B |
Throughput/Crank Report ⚡Throughput results for AspNetCoreSimpleController comparing the following branches/commits: Cases where throughput results for the PR are worse than latest master (5% drop or greater), results are shown in red. Note that these results are based on a single point-in-time result for each branch. For full results, see one of the many, many dashboards! gantt
title Throughput Linux x64 (Total requests)
dateFormat X
axisFormat %s
section Baseline
This PR (6362) (11.354M) : 0, 11354041
master (11.171M) : 0, 11171321
benchmarks/2.9.0 (11.033M) : 0, 11032866
section Automatic
This PR (6362) (7.309M) : 0, 7309149
master (7.220M) : 0, 7220293
benchmarks/2.9.0 (7.786M) : 0, 7785853
section Trace stats
master (7.672M) : 0, 7672287
section Manual
master (11.297M) : 0, 11297089
section Manual + Automatic
This PR (6362) (6.671M) : 0, 6670901
master (6.666M) : 0, 6665729
section DD_TRACE_ENABLED=0
master (10.155M) : 0, 10155271
gantt
title Throughput Linux arm64 (Total requests)
dateFormat X
axisFormat %s
section Baseline
This PR (6362) (9.638M) : 0, 9638059
master (9.792M) : 0, 9792239
benchmarks/2.9.0 (9.495M) : 0, 9494821
section Automatic
This PR (6362) (6.504M) : 0, 6503694
master (6.460M) : 0, 6460434
section Trace stats
master (6.580M) : 0, 6580287
section Manual
master (9.509M) : 0, 9508789
section Manual + Automatic
This PR (6362) (5.904M) : 0, 5903531
master (5.968M) : 0, 5968264
section DD_TRACE_ENABLED=0
master (8.863M) : 0, 8863124
gantt
title Throughput Windows x64 (Total requests)
dateFormat X
axisFormat %s
section Baseline
This PR (6362) (10.114M) : 0, 10114056
master (9.925M) : 0, 9924990
benchmarks/2.9.0 (10.020M) : 0, 10019592
section Automatic
This PR (6362) (6.674M) : 0, 6673595
master (6.383M) : 0, 6383332
benchmarks/2.9.0 (7.255M) : 0, 7255257
section Trace stats
master (7.050M) : 0, 7050172
section Manual
master (9.974M) : 0, 9974221
section Manual + Automatic
This PR (6362) (6.380M) : 0, 6379711
master (5.768M) : 0, 5768402
section DD_TRACE_ENABLED=0
master (9.135M) : 0, 9134686
|
I've confirmed it's true. The native side still waits for a call from the managed side (to know what to enable apart from anything else) Plus... that code is already merged, and this works so... 😄 |
Yes, initialization is still done when managed library is loaded and calls similar methods as before, but withouth marshalling all the definitions, which are retrieved from the native side directly. But the root methods keep being the same, so, the same behavior should be expected. |
veerbia
pushed a commit
that referenced
this pull request
Dec 16, 2024
## Summary of changes Bail out in the managed loader if we're in a no-dynamic code scenario ## Reason for change Our automatic instrumentation is currently inherently tied to emitting dynamic code (Duck typing). In no-dynamic-code scenarios we will likely end up crashing (or giving a very degraded experience, with a performance hit at the very least). It's better to bail out early than do that ## Implementation details Check for the `System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupported` app context switch in the managed loader. This controls the `RuntimeFeature.IsDynamicCodeSupported` flag, which in turn determines whether the app auto-bails out in .NET 8+. Note that this flag is set when you add `<PublishAot>` to your project _even if you don't publish with AOT_. I imagine there are some other environments (pre .NET 8) in which dynamic code is not available, but I don't know if we need to worry about them ## Test coverage Added an integration tests that sets the flag and confirms we don't get traces when the flag is set to `false` ## Other details I had to add a helper to the `TestHelper` to pass runtime arguments to `dotnet`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary of changes
Bail out in the managed loader if we're in a no-dynamic code scenario
Reason for change
Our automatic instrumentation is currently inherently tied to emitting dynamic code (Duck typing). In no-dynamic-code scenarios we will likely end up crashing (or giving a very degraded experience, with a performance hit at the very least). It's better to bail out early than do that
Implementation details
Check for the
System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupportedapp context switch in the managed loader. This controls theRuntimeFeature.IsDynamicCodeSupportedflag, which in turn determines whether the app auto-bails out in .NET 8+.Note that this flag is set when you add
<PublishAot>to your project even if you don't publish with AOT. I imagine there are some other environments (pre .NET 8) in which dynamic code is not available, but I don't know if we need to worry about themTest coverage
Added an integration tests that sets the flag and confirms we don't get traces when the flag is set to
falseOther details
I had to add a helper to the
TestHelperto pass runtime arguments todotnet