Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Early work to make it possible to call the interpreter from ReadyToRun code #2910

Open
wants to merge 1 commit into
base: feature/CoreclrInterpreter
Choose a base branch
from

Conversation

cshung
Copy link
Member

@cshung cshung commented Jan 6, 2025

This prototype implements the most basic version of ready to run support to let the interpreter to work with ready to run code. It is far from complete. Right now, it can

  • Call any ReadyToRun code from the interpreter, by choosing not to use InterpreterPrecode in method.cpp, and
  • call static, parameterless method from ReadyToRun code to interpreter, using a few redirections.

This is for Windows, x64 only.

  1. When ReadyToRun code calls a method for the first time, it will end up in ExternalMethodFixupWorker to determine eventually where that will go.
  2. If the runtime decide it should be interpreted, it need to do some preparation work:

2.1 Create the InterpreterMethodInfo object and make it available through the newly introduced InterpreterImport redirection cell, and
2.2 Redirect the call to a InterpreterStub that will do two things:

  • Move the address of the InterpreterMethodInfo object from the InterpreterImport redirection cell to rcx, and then
  • Jump to the interpreter entry point, which is made available though an eager import that we prepared earlier during assembly load for the ready to run image.

With that the interpreter will get the interpreter method info and work on it and return to the original caller.

The AppContext changes are just so I can test making these calls - the math is there just to avoid optimization.

To test this out, simply run any application (since it will run AppContext setup and fail there regardless) with the same set of environment variables as before but turn on DOTNET_ReadyToRun.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant