PMI: options for using local .Net Core builds
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 20/100
Research direction
Start by reading the PMI workflow described around DRIVEALL and PREPONE, then compare the local-build and CLI approaches with the coreclr local NuGet instructions and Benchmark Dot Net. A completed design would choose and document an approach for local .NET Core builds, child-process execution, method-focused runs, and PMI-specific COMPlus filtering.
Written by the indexing model from the issue text.
Description
As part of dev inner loop workflow it will be common to want to run PMI on local .Net Core builds. Here are some initial ideas on various approaches we could take.
For diffing and correctness checking we would like to use a checked build of the jit. So we either need a jit build that is compatible with the host CLI, or else we need a way to invoke a simpler locally built runner (say corerun).
For robustness we initially will likely use DRIVEALL to run the locally built jit in a child process, so we can push past asserts.
Once a particular method becomes interesting (from an assert or asm diff) we can use PREPONE to look at just that method. Currently that does not use a child process. So perhaps we need a DRIVEONE to parallel DRIVEALL.
If we go the CLI route, we can use the instructions in coreclr for using local nuget packages. This perhaps is most simply done by cloning the project file and adding new entries for the runtime. Or we can publish and then patch. It might make sense to always run the jit under test as an altjit. This would mean the cross-arch and self-arch jitting workflows would be the same.
Benchmark Dot Net seemingly solves similar issues and it might be interesting to consider adopting their approach; this would conceptually allow cross-runtime diffing (say comparing .net core vs .net framework codegen, or .net vs mono).
We probably want custom complus settings to apply only to the methods jitted via PMI. Even if we prejit/crossgen PMI.exe there will still be some residual jitting from SIMD methods in the core library. So we might need an assembly-inclusive altjit filter (currently there's only an exclusion list).
- Dominant language
- C#
- Stars
- 161
- Forks
- 69
- Avg merge
- 8d 1h
- Merged PRs (30d)
- 2
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from dotnet/jitutils
-
Difficulty 2/5 1-2 days Newbie friendliness 62/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 45/100
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
Similar issues
-
copilot documentation
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 2 days
-
needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
spectreconsole/spectre.console#2221 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
godotengine/godot-docs#12428 ·
Maintainers usually reply within 1 day
-
.NET triage
Difficulty 2/5 1-3 hours Newbie friendliness 73/100
microsoft/semantic-kernel#14526 ·
Maintainers usually reply within 4 days