You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CoreCLR runtime doesn’t currently support platforms that don’t allow runtime executable code generation, like iOS, macCatalyst or WASM. There are runtime helpers and stubs that are generated by the runtime. And even with ReadyToRun (R2R) assemblies, JIT is still needed for some cases where crossgen cannot precompile methods for various reasons.
To allow usage of CoreCLR runtime on such platforms, it was decided to implement an interpreter for CoreCLR. During an experiment last autumn, the Mono interpreter was analyzed in detail, and it was decided that it can be used as a basis for a new CoreCLR interpreter implementation.
Besides interpreter implementation, it is also necessary to make CoreCLR capable of working without any runtime executable code generation. So, part of the work focuses on replacing or reimplementing the helpers so that no executable code is generated at runtime.
Natural part of the work is also ensuring that diagnostic tools can work with the interpreter. These tools include the SOS plugin and debugger related code in the CoreCLR responsible for setting breakpoints, single stepping, examining locals and arguments in the frames of interpreted functions and viewing stack trace with interpreted methods on the stack. More complex scenarios like EnC are out of scope of the work in .NET 10 timeframe.
The planned work is divided into five workstreams:
CoreCLR runtime changes (excluding diagnostics)
Mono interpreter porting
Ensuring CoreCLR doesn’t generate any executable code at runtime
Diagnostics
iOS with CoreCLR
WASM with CoreCLR
The work is split into six milestones (M1 to M6). The actual work is tracked by sub-issues per each workstream:
CoreCLR runtime doesn’t currently support platforms that don’t allow runtime executable code generation, like iOS, macCatalyst or WASM. There are runtime helpers and stubs that are generated by the runtime. And even with ReadyToRun (R2R) assemblies, JIT is still needed for some cases where crossgen cannot precompile methods for various reasons.
To allow usage of CoreCLR runtime on such platforms, it was decided to implement an interpreter for CoreCLR. During an experiment last autumn, the Mono interpreter was analyzed in detail, and it was decided that it can be used as a basis for a new CoreCLR interpreter implementation.
Besides interpreter implementation, it is also necessary to make CoreCLR capable of working without any runtime executable code generation. So, part of the work focuses on replacing or reimplementing the helpers so that no executable code is generated at runtime.
Natural part of the work is also ensuring that diagnostic tools can work with the interpreter. These tools include the SOS plugin and debugger related code in the CoreCLR responsible for setting breakpoints, single stepping, examining locals and arguments in the frames of interpreted functions and viewing stack trace with interpreted methods on the stack. More complex scenarios like EnC are out of scope of the work in .NET 10 timeframe.
The planned work is divided into five workstreams:
The work is split into six milestones (M1 to M6). The actual work is tracked by sub-issues per each workstream:
The text was updated successfully, but these errors were encountered: