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

Abierto
  • ¿Algo no está bien?
#137,107 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
44/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
csharp, wasm
Área
backend, performance

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
C#
Estrellas
18.4k
Forks
5.8k
Merge medio
2 d 19 h
PR fusionados (30 d)
590

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de dotnet/runtime

Todos los issues de dotnet/runtime

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.