Runtime & concurrency
Reveal answer and reasoning
Runtime capability flags describe whether dynamic code is supported or compiled in that execution environment. They do not report the optimization history of a specific method. A repeated-call loop can warm some paths and verify stable behavior, but it does not prove Tier1 promotion, inlining choices, or a universal steady state. The lesson therefore separates exact behavioral stdout from actual variable diagnostics on the desktop process's stderr.
The portable example knows only that Work returns the expected forty-five and repeats consistently. A common wrong answer declares the twentieth call optimized or interprets a shorter second duration as proof of a tier transition. Debug configuration, runtime settings, startup, instrumentation, and execution model affect the observation. If the question concerns a particular code version, use diagnostics that actually identify that code generation, and do not transfer desktop JIT conclusions to an interpreter or NativeAOT environment that follows another strategy.
What a strong answer covers
- Capability is not per-method tier evidence.
- Warmup counts alone do not prove optimization.
- Configuration and actual code-generation diagnostics matter.
Common pitfall
Treating a repeated-call count or one shorter duration as proof of Tier1 compilation.
Follow-up questions
- Why can a stable wrong answer still pass a self-comparison?
- What does Debug versus Release change in an investigation?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.