| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Add some perf events/data for tiered compilation
New events:
- `Settings` - Sent when TC is enabled
- `Flags` - Currently indicates whether QuickJit and QuickJitForLoops are enabled
- `Pause` - Sent when TC is paused (due to a new method being called for the first time)
- `Resume` - Sent when TC resumes
- `NewMethodCount` - Number of methods called for the first time while tiering was paused
- `BackgroundJitStart` - Sent when starting to JIT methods in the background
- `PendingMethodCount` - Number of methods currently scheduled for background JIT
- `BackgroundJitStop` - Sent when background jitting stops
- `PendingMethodCount` - Same as above. When 0, background jitting has completed.
- `JittedMethodCount` - Number of methods jitted in the background since the previous BackgroundJitStart event on the same thread
Miscellaneous:
- Updated method JIT events to include the optimization tier
- Added a couple more cases where tiered compilation is disabled for methods that have JIT optimization disabled for some reason
- Renamed `Duration` field of the new version of the `ContentionEnd` to `DurationNs` to indicate the units of time
- Added `OptimizationTierOptimized` to `NativeCodeVersion::OptimizationTier` to distinguish it from `OptimizationTier1`. `OptimizationTierOptimized` is now used for methods that QuickJit is disabled for, and does not send the tier 1 flag.
- For info about the code being generated by the JIT, added info to `PrepareCodeConfig` and stored a pointer to it on the thread object for the current JIT invocation. Info is updated in `PrepareCodeConfig` and used for updating the tier on the code version and for sending the ETL event.
- If the JIT decides to use MinOpt when `MethodDesc::IsJitOptimizationDisabled()` is false, the info is not stored. The runtime method event will reflect the JIT's choice, the rundown event will not.
- Updated to show optimization tiers in SOS similarly to PerfView
|
|
Fix incorrect tier reported by SOS
- The tier of the initial code version was being assumed to be 0
- Whether call counting is enabled for a method needed to be available to the DAC
- Some small renames / cleanup to simplify code
|
|
- With multi-core JIT, a method may be jitted before it is called, in which case the call counting entry would not already exist
|
|
Add config option to disable tier 0 JIT
Fixes https://github.com/dotnet/coreclr/issues/21856
- For methods that don't have pregenerated code, using tier 0 JIT can improve startup perf, and disabling tier 0 JIT can be useful to sacrifice some startup time to avoid issues of running tier 0 code for too long. In some cases, it may also be desirable to avoid tiering up much later.
- A fixed value for the call count indicates that tier 0 call counting is disabled. When disabled, the method starts at tier 1.
- Also modified call counting to start from a predetermined threshold and count down to zero, as it simplifies some things, allows for methods to have different thresholds, and likely is what we would want eventually anyway
- Took a small step towards eliminating knowledge of specific tier levels in code that should not care, though more is to be done there
|
|
Enable tiered jitting for R2R methods
- Included R2R methods and generics over value types in CoreLib for tiered jitting. Tier 0 for R2R methods is the precompiled code if available, and tier 1 is selectively scheduled based on call counting.
- Added a delay before starting to count calls for tier 1 promotion. The delay is a short duration after frequent tier 0 jitting stops (current heuristic for identifying startup).
- Startup time and steady-state performance have improved on JitBench. There is a regression shortly following startup due to call counting and tier 1 jitting, for a short duration before steady-state performance stabilizes.
- Added two new config values, one for configuring the call count threshold for promoting to tier 1, and another for specifying the delay from the last tier 0 JIT invocation before starting to count calls
|
|
This makes tiered compilation work properly with profiler ReJIT, and positions the runtime to integrate other versioning related features together in the future. See the newly added code-versioning design-doc in this commit for more information.
Breaking changes for profilers: See code-versioning-profiler-breaking-changes.md for more details.
|
|
Tiered compilation is a new feature we are experimenting with that aims to improve startup times. Initially we jit methods non-optimized, then switch to an optimized version once the method has been called a number of times. More details about the current feature operation are in the comments of TieredCompilation.cpp.
This is only the first step in a longer process building the feature. The primary goal for now is to avoid regressing any runtime behavior in the shipping configuration in which the complus variable is OFF, while putting enough code in place that we can measure performance in the daily builds and make incremental progress visible to collaborators and reviewers. The design of the TieredCompilationManager is likely to change substantively, and the call counter may also change.
|
