Read or download the complete SDK project, then follow its setup on your computer. The separate C# companion practice below runs in SharpRune’s .NET 9 console environment.
The runtime contract
Runtime dynamic-code capability, JIT compilation, and tiered optimization are related but different questions. A runtime capability flag does not identify which tier a particular method currently uses, and repeating a function does not prove an optimization transition happened. The portable companion checks only that a small deterministic calculation remains semantically stable across repeated calls. The external desktop project additionally records actual runtime flags and elapsed ticks on stderr. Those diagnostics are observations from that run, not portable timing promises or a fabricated report that SharpRune's browser runtime has a desktop JIT.
Trace the portable program
Work sums integers from zero through nine, so the first result is forty-five. Twenty additional portable calls are compared with that retained result, and stable remains true. The two output lines are value:45 and stable:True. The desktop lab performs more bounded calls and preserves the same exact behavioral stdout while writing its actual dynamic-code flags and measured duration separately. Neither loop counts machine-code recompilations. A common wrong answer treats an arbitrary warmup count as conclusive evidence that Tier1 must now exist or that the next call is guaranteed faster.
Execute the actual desktop lab
The external lab writes its actual dynamic-code support and compilation flags with elapsed ticks to stderr, while stdout preserves the independently expected value and stability check. Those flags describe runtime capabilities and strategy, not the optimization history of Work. The project is an ordinary desktop build, and its default Debug run is a demonstration of observation mechanics rather than a benchmark. A Release configuration, runtime settings, process startup, and real code-generation diagnostics all matter if the question is whether a particular method was promoted or optimized. The sample deliberately supplies none of those missing conclusions from a loop count.
Pitfalls and boundary limits
Tiered compilation can change generated code over time, but a method may also be inlined, optimized differently, excluded from a particular optimization path, or executed by a runtime without a desktop JIT. Warmup can reduce some startup effects without proving one universal steady state. Stopwatch ticks include the chosen measured scope and are not automatically nanoseconds. A stable arithmetic answer also does not imply identical performance or allocation. Keep the semantic oracle forty-five independent of any measured duration, and do not turn one machine's capability flags into a claim about Mono/WebAssembly, NativeAOT, or every deployment of .NET 10.
Practice one: isolate behavior
First change Work's count to five and predict ten from the arithmetic series, then keep the repeated-call equality check. Hint: preserve the direct expected answer as well as the stability comparison; a constant wrong implementation can be stable. Compare the external diagnostics from two separate process runs without requiring equal elapsed ticks. Record the configuration and runtime for each observation. Do not label a shorter second run as proven Tier1 behavior merely because the displayed result stayed correct and the measurement happened to decrease.
Practice two: design and verify
For another exercise, prepare an actual Release-run investigation with tiering enabled and disabled through documented runtime configuration. State what evidence would identify the method's code generation rather than merely its elapsed time. Hint: use appropriate runtime diagnostics or disassembly in a separate supported environment, and retain equivalent workloads and correctness checks. Keep startup measurements separate from repeated-operation measurements. If the application runs under an interpreter or AOT, choose a question appropriate to that execution model instead of forcing a desktop tier-promotion story onto observations that cannot establish it.
Review the evidence
Review runtime-performance claims by separating capability, configuration, observed code generation, workload, and result correctness. The portable companion verifies only arithmetic and stability. The external project adds real flags and timing observations but does not claim a tier transition, benchmark result, or cross-runtime speedup. That restraint is part of useful measurement: an honest small observation can guide the next experiment without pretending to answer a larger question. Preserve the measured scope and the environment alongside numbers, and do not let the availability of a timer replace the evidence needed for a specific JIT or tiering conclusion. Record Debug versus Release configuration and whether a debugger was attached alongside diagnostics, rather than letting an unlabeled duration imply a controlled comparison.
JIT capability is not a tiering measurement — desktop runtime lab
Set up the SDK project
- Save both files at their exact paths in a fresh owned directory.
- Use a .NET 10 SDK, then run dotnet run --project RuntimeLab.csproj. This project intentionally uses C# 13 syntax.
- Workers and waits are bounded; a timeout or a violated invariant fails the process. No benchmark or NativeAOT publication is implied by an ordinary run.
Download complete SDK project ↗
Project files
Program.cs
Download file ↗using System;
using System.Linq;
using System.Collections.Generic;
using System.Collections.Concurrent;
using System.Reflection;
using System.Linq.Expressions;
using System.Threading;
using System.Threading.Tasks;
var watch = System.Diagnostics.Stopwatch.StartNew();
int first = Work(10);
bool stable = true;
for (int run = 0; run < 2000; run++) stable &= Work(10) == first;
watch.Stop();
Console.WriteLine($"value:{first}");
Console.WriteLine($"stable:{stable}");
Console.Error.WriteLine($"dynamic-supported:{System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupported};dynamic-compiled:{System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeCompiled};elapsed-ticks:{watch.ElapsedTicks}");
static int Work(int count) { int total = 0; for (int i = 0; i < count; i++) total = checked(total + i); return total; }
RuntimeLab.csproj
Download file ↗<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net10.0</TargetFramework>
<LangVersion>13.0</LangVersion>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
<PublishAot>false</PublishAot>
</PropertyGroup>
</Project>
Expected result
Exact behavioral stdout on the stated desktop lab: value:45 stable:True Variable diagnostics, where emitted, go to stderr and must not be treated as portable timing or allocation guarantees.
Use the listed SDK and dependencies for this project. Open C# practice runs the separate portable exercise.
C# companion practice
using System;
using System.Linq;
using System.Collections.Generic;
using System.Collections.Concurrent;
using System.Reflection;
using System.Linq.Expressions;
using System.Threading;
using System.Threading.Tasks;
int first = Work(10);
bool stable = true;
for (int run = 0; run < 20; run++) stable &= Work(10) == first;
Console.WriteLine($"value:{first}");
Console.WriteLine($"stable:{stable}");
static int Work(int count) { int total = 0; for (int i = 0; i < count; i++) total = checked(total + i); return total; }
C# practice output
value:45 stable:True
Repeated equal answers verify behavior, not that Tier1 compiled. The external lab records actual dynamic-code flags separately on stderr.