Add field access support to CoreCLR Interpreter #114049
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ghost
added
the
area-CodeGen-coreclr
There was a problem hiding this comment.
Pull Request Overview
This PR introduces support for field access in the CoreCLR Interpreter by adding object creation, instance/static field operations, and ThreadStatic field handling.
- Added new structs and classes (MyStruct, MyObj, MyStruct2) to facilitate the tests
- Introduced tests (TestJitFields, TestFields, TestSpecialFields) to verify field access behavior
- Included helper methods to read and write integers via references
Files not reviewed (4)
- src/coreclr/interpreter/compiler.h: Language not supported
- src/coreclr/interpreter/intops.def: Language not supported
- src/coreclr/interpreter/intops.h: Language not supported
- src/coreclr/vm/interpexec.cpp: Language not supported
Comments suppressed due to low confidence (2)
src/tests/JIT/interpreter/Interpreter.cs:19
- [nitpick] Consider renaming 'ct' to a more descriptive name like 'counter' to improve code clarity.
public int ct;
src/tests/JIT/interpreter/Interpreter.cs:178
- [nitpick] TestSpecialFields currently verifies ThreadStatic field behavior only on the main thread; consider adding tests with multiple threads to ensure proper isolation.
public static bool TestSpecialFields()
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
BrzVlad
added
area-CodeGen-Interpreter-coreclr
and removed
area-CodeGen-coreclr
jkotas
reviewed
Mar 31, 2025
jkotas
reviewed
Mar 31, 2025
BrzVlad
force-pushed
the
feature-clr-interp3
branch
from
802ebeb to
6931c95
Compare
janvorli
reviewed
Mar 31, 2025
| ctorClass = m_compHnd->getMethodClass(ctorMethod); | ||
| int32_t numArgs = ctorSignature.numArgs; | ||
|
|
||
| // TODO Special case array ctor / string ctor |
There was a problem hiding this comment.
A nit - I've been using Interpreter-TODO instead of just TODO so that we can quickly search through the code base for them. It seems it would make sense to use it in the interpreter code too.
This was referenced Mar 31, 2025
BrzVlad
force-pushed
the
feature-clr-interp3
branch
2 times, most recently
from
86a7583 to
b48a187
Compare
The newobj instruction receives the set of arguments and it needs to create the object in question, add it as the `this` argument to the constructor and return it as well. All this work is done by a single interpreter newobj instruction. Once handling the creation of the new object, the already existing call path is reused for executing the constructor. The newobj instruction thinks it receives the `this` pointer as an argument, so we can reuse the offset allocator to generate the exact offsets for each argument. We dummy initialize `this` via an intermediary opcode, so the offset allocator handles this pattern cleanly.
We currently have limited control over what is interpreted and what is jitted. When creating a new object in the interpreter we have the problem of having to call to object ctor which is jitted. A simple work around, at least for now, is to ignore this call.
Loading and storing into instance and static fields, as well as loading the address of fields. For instance fields, this is achieved via ldind/stind opcodes, that have the offset embedded into the instruction. For static fields, we first compute the field address and then we reuse the same ldind/stind opcodes for the field access. When loading a field from a valuetype from the interpreter stack, we use a separate opcode INTOP_MOV_SRC_OFF, which will be emitted as a normal move (with already existing opcodes), but the source offset that it operates on can point inside a VT var.
Special static fields can have a bunch of accessors. This commit handles a few accessor types for thread static fields. In order to obtain the address of such a field, we emit an interpreter opcode that can call a helper of a certain signature, with the slot containing the helper code pointer and argument embedded in the code stream. It seems like the helpers can either point to native code or to jit compiled code.
Reuse the instructions used for loading/storing into fields
For simplicity we emit full memory barriers each time
Some of them are allocating objects so we disable them currently just to be safe on CI.
BrzVlad
force-pushed
the
feature-clr-interp3
branch
from
b48a187 to
0acc620
Compare
This was referenced Apr 2, 2025
|
/ba-g the failures are unrelated to this change, they happen on every PR for the past few days. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds support for creating new objects and for loading and storing into instance and static fields. As an experiment on what it would be necessary, support was added also for ThreadStatic fields. Support for indirect loads and stores was also added.
PR can be reviewed commit by commit.