[wasm][R2R] Interface calls go through CORINFO_HELP_VIRTUAL_FUNC_PTR instead of a dispatch cell

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

Maintainer thường phản hồi trong vòng 1 ngày

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

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
44/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
csharp, wasm
Lĩnh vực
backend, performance

Hướng nghiên cứu

Start in CorInfoImpl.ReadyToRun.cs at the Target.IsWasm && targetMethod.OwningType.IsInterface branch described in the issue, then compare it with the CORINFO_VIRTUALCALL_STUB path used on other targets and the external-method thunk work in #133146. Work is complete when wasm R2R interface calls use a dispatch cell instead of CORINFO_HELP_VIRTUAL_FUNC_PTR; verify the generated code no longer has those helper calls in the stated IndexOfAny case.

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

Mô tả

arch-wasm area-ReadyToRun tenet-performance
Description

On browser-wasm, crossgen2 compiles every interface call as CORINFO_VIRTUALCALL_LDVIRTFTN. That is the Target.IsWasm && targetMethod.OwningType.IsInterface branch in CorInfoImpl.ReadyToRun.cs (around line 2490). Each interface call becomes a CORINFO_HELP_VIRTUAL_FUNC_PTR helper call followed by a call_indirect. In shared generic code the helper first needs two generic lookups, one for the class handle and one for the method handle.

Other targets use CORINFO_VIRTUALCALL_STUB, which calls through a single looked-up dispatch cell. Class-virtual calls on wasm moved to external-method thunks in #133146; interface calls didn't.

Configuration
  • Current main, checked clrjit_universal_wasm_arm64 with crossgen2 --targetos:browser --targetarch:wasm -O.
  • Comparison: checked osx-arm64 JIT with crossgen2 --targetos:osx --targetarch:arm64 -O.
Regression?

No. This is the current wasm R2R design.

Data

Static codegen only, System.SpanHelpers:IndexOfAny[System.__Canon](byref,System.__Canon,System.__Canon,int) in System.Private.CoreLib, where value0.Equals(lookUp) is a constrained call through IEquatable<T>:

VIRTUAL_FUNC_PTR calls
browser-wasm R2R 28
osx-arm64 R2R 0

On osx-arm64 the call loads its target from one looked-up cell (ldr x2, [x11]; blr x2).

Analysis

Split out of #136723 (generic lookups not hoisted), which mentions this as a likely larger cost on wasm. Relates to the wasm CoreCLR performance tracking issue #124218.

[!NOTE]
This issue was generated with GitHub Copilot.

Ngôn ngữ chính
C#
Star
18.4k
Fork
5.8k
Merge trung bình
2 ngày 19 giờ
Pull request đã merge (30 ngày)
590

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

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

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/runtime

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

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.