Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

PMI: options for using local .Net Core builds

Đang mở
  • Có gì không ổn?
#129 4 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
20/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Công nghệ
csharp
Lĩnh vực
tooling

Hướng nghiên cứu

Bắt đầu bằng cách đọc quy trình workflow PMI được mô tả xung quanh DRIVEALL và PREPONE, sau đó so sánh các cách tiếp cận build cục bộ và CLI với hướng dẫn NuGet cục bộ của coreclr và Benchmark Dot Net. Một thiết kế hoàn chỉnh sẽ lựa chọn và ghi lại một cách tiếp cận cho các bản build .NET Core cục bộ, việc thực thi tiến trình con, các lần chạy tập trung vào phương thức và việc lọc COMPlus dành riêng cho PMI.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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).

Ngôn ngữ chính
C#
Star
159
Fork
69
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của dotnet/jitutils

Tất cả issue của dotnet/jitutils

Issue tương tự

Thêm issue về C#

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.