Allocate GC statics on the pinned object heap #870
Conversation
This allows us to get rid of a level of indirection when accessing GC static fields.
MichalStrehovsky
added
the
area-NativeAOT-coreclr
|
Cc @yowl - this is removing an indirection when accessing GC static bases - I assume the WASM side will be a one-liner delete, like in the R2R helper nodes in this pull request. |
| @@ -27,17 +29,25 @@ public static partial class StartupCodeHelpers | |||
| /// </summary> | |||
| private static int s_moduleCount; | |||
|
|
|||
| /// <summary> | |||
| /// GC handle of an array with s_moduleCount elements, each representing and array of GC static bases of the types in the module. | |||
There was a problem hiding this comment.
| /// GC handle of an array with s_moduleCount elements, each representing and array of GC static bases of the types in the module. | |
| /// GC handle of an array with s_moduleCount elements, each representing an array of GC static bases of the types in the module. |
| max_object_size = (INT32_MAX - 7 - min_obj_size); | ||
| } | ||
|
|
||
| if (size >= max_object_size) |
There was a problem hiding this comment.
Yup, it's checked in the newly factored out GcAllocInternal. We had all of this duplicated between RhpGcAlloc and AllocateNewArrayImpl. Instead of adding a third copy for AllocateNewObjectImpl, I'm funneling it all to the common helper. But please double check, I would hate to mess this up.
|
Does the removed indirection mean that statics can be debug evaluated now? |
I think it would also be possible before although this still has one extra indirection compared to statics in C++ (statics in C++ are simply allocated in the data section of the executable - here they're on the GC heap and symbols can't refer to the GC heap directly). I think we're not generating the debug info in the format the debugger expects. I haven't look what VC++ generates. |
This allows us to get rid of a level of indirection when accessing GC static fields.
Fixes #841.