Separate code manager for the interpreter

[janvorli]

This change adds a separate code manager for the interpreted code. Here is a high level overview of the changes:

• A base class EECodeGenManager was extracted from the EEJitManager
• A new class InterpreterJitManager derived from the EECodeGenManager was added and implemented.
• Similarly, a base class CEECodeGenInfo was extracted from the CEEJitInfo
• A new class CInterpreterJitInfo derived from the CEECodeGenInfo was added and implemented
• The CodeHeader and RealCodeHeader became base classes and JitCodeHeader, RealJitCodeHeader, InterpreterCodeHeader and RealInterpreterCodeHeader were added. The CodeHeader derivates don't add any extra data, the JitCodeHeader just provides the methods that are needed to access Jit specific members of the RealJitCodeHeader.
• The UnsafeJitFunction was refactored so that the interpreter (if enabled) is invoked first and then the AltJit / Jit ones are called.
• A new DOTNET_Interpreter, DOTNET_InterpreterPath and DOTNET_InterpreterName env vars are added to match the existing AltJit ones.

PR Overview

This PR introduces a separate code manager dedicated to the interpreter by extracting base classes and adding new interpreter-derived classes for code generation and management.

• Extracted EECodeGenManager and CEECodeGenInfo base classes; added InterpreterJitManager and CInterpreterJitInfo.
• Updated headers to include interpreter-specific versions alongside JIT ones.
• Revised test configuration to use new interpreter environment variables instead of AltJit ones.

Reviewed Changes

File	Description
src/tests/JIT/interpreter/InterpreterTester.cs	Updates the test environment variables to use interpreter-specific keys, ensuring consistency with the new code manager changes.

Copilot reviewed 16 out of 16 changed files in this pull request and generated no comments.

[janvorli]

cc: @BrzVlad

[max-charlamb]

This conflicts with #111759 because cDAC starts to use the RealCodeHeader offsets for nUnwindInfos and unwindInfos that this PR moves to the JitRealCodeHeader. The cDAC does not currently support the interpreter so I think it only cares about the JitRealCodeHeader right now and we should change the datadescriptors to use that instead of the new base class. This would be a breaking cDAC change and require the DataType name to change on the managed side too, but there isn't any impact.

https://github.com/dotnet/runtime/pull/111759/files#diff-d10a483484c15e47b5c1d129ff70b1bb88ad775e8f113475f8789aad1a4ffad5

@davidwrighton

[jkotas]

This conflicts with #111759 because cDAC starts to use the RealCodeHeader offsets for nUnwindInfos and unwindInfos that this PR moves to the JitRealCodeHeader

My preference would be to solve this by avoiding coupling between the JIT code manager and interpreter code manager. Leave the existing code header for JITed code alone, and define a dedicated code header for interpreted code. There is going to be some duplication for now and that's fine. The advantage is that it allows each of them to evolve independently.

[janvorli]

I am not sure I understand why cdac depends on the name of the code header. The JitCodeHeader / RealJitCodeHeader in my PR are not different from the old CodeHeader / RealCodeHeader, they are just renames of the old ones.

My preference would be to solve this by avoiding coupling between the JIT code manager and interpreter code manager.

@jkotas do you mean instead of the shared EECodeGenManager base class to have the InterpreterJitManager a copy of almost all of the code from the EEJitManager?

[jkotas]

I am not sure I understand why cdac depends on the name of the code header

cdac infrastructure expects the data contract type representation to match the implementation. If you split a type into two types without actually changing the layout, it changes the data contract. You are right that the contract type representation does not have to match the implementation. There is probably a way how to convince the cdac infrastructure to deal with the divergence, but it is not how it is usually done. I am not sure whether we have a prior example.

do you mean instead of the shared EECodeGenManager base class to have the InterpreterJitManager a copy of almost all of the code from the EEJitManager?

I am concerned about the code header. I think we want the interpreter bytecode header to be decoupled from JITed code header, so we are free to change one in any way we want without impacting the other.

I do not have a strong opinion whether it should be implemented as inheritance hierarchy, or as two types calling into static helpers to facilitate code sharing.

[janvorli]

Ah, so the concern is just the code header and the code that works with it, that makes sense. I also think we may eventually diverge the interpreter and jit code header. I was thinking you were talking about all of the code in the code manager.

[janvorli]

I've tried to run the dotnet/performance microbenchmarks for EH. All of them are about 5% worse with the last change that separates the code headers completely. With the initial change, the difference was < 2%. I need to think about some other way to solve the code header separation.

[janvorli]

I have reworked it and got rid of all of the regression. I will update this PR on Monday

[janvorli]

@jkotas can you please take another look? The code headers are now completely separated.

[janvorli]

@jkotas I have updated the PR based on your feedback.

[janvorli]

/ba-g the wasm failure is unrelated and it is a known infra issue.