[coreCLR][interp] Limitations we're not planning to address right now

Open
#118,965 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
cpp, ios, wasm

Research direction

The issue names no files, tests, or entry points. Start by reviewing the limitation checklist and the linked mixed-mode debugging issue; any contribution would need a separately scoped limitation with an agreed change and validation criteria.

Written by the indexing model from the issue text.

Description

area-CodeGen-Interpreter-coreclr

This is a list (not all inclusive and in no particular order) of limitations in the interpreter and/or runtime that we don't currently plan to address but may make plans to address in the future.

  • Tiered compilation causes crashes in the interpreter if it recompiles an interpreted method. We currently disable tiered compilation if the interpreter is enabled at all.
  • Many invocations go through stubs that don't need to, i.e. interpreter-to-interpreter invocations of pinvokes or delegates. This will need to be addressed eventually for WASM and iOS but is not currently causing problems.
  • Mixed-mode debugging does not work reliably and will trigger assertions or fail to properly walk the stack.
  • We do not put debug fill patterns (0xCDCDCDCD) in place of local variables that have their address exposed like the JIT does. This breaks JIT\Directed\debugging\poisoning\poison.
  • Varargs, managed C++, exception handling interop, built-in COM interop, and other Windows specific runtime features
  • Marshalled calli
  • COM support
  • Interop with externally thrown C++/SEH exceptions
  • Values on the IL stack are reported conservatively to the GC
Dominant language
C#
Stars
18.3k
Forks
5.6k
PR merge metrics
PR metrics pending

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dotnet/runtime

All issues in dotnet/runtime

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.