-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Make normal statics simpler #99183
Make normal statics simpler #99183
Changes from 100 commits
b57c72b
e47278b
34420e0
3cb0324
37e2555
78720e1
c375996
5ec61b2
e88cda8
2eb6eb8
aa741bc
f805eda
d463f59
6aed90a
1bb643a
02ee7a1
e3e8cd6
92153b0
a8f9b73
d37f612
0c0545e
6a9a062
abe8a97
3380e00
785f32f
504d93e
8afc63e
b8ef938
fce7f9f
8bd309c
6cb70fa
7db100e
1595cf0
961744d
69de672
57c3025
94b58ed
170f74c
87ae678
a1b5e17
4543b03
53a68a0
378ecc1
f38ae83
66cd564
0e7c1d4
446a60e
b2850ea
d526181
e2aa42f
24801db
662579b
43e4e52
37ee3e9
07f7d14
cd157be
e8273e6
4b27a95
f111ecd
f6aaa69
61823a4
99c678a
5914558
4563623
11c671f
bc16c62
ec88375
0ef9bb1
53cd1f6
160acba
cacb466
1053165
43abbf3
42fffaa
8d9ddba
35c935e
d48ef55
638ea50
bcff9aa
fc67ecd
4e2e0c2
4e78250
02b5899
100c2ad
3888af5
270e991
2db5ffd
0be084d
8d7243b
b08d8eb
a94b00c
3b94fa0
e702b91
ecd26bc
42f3eb9
a6225c1
548842e
e6f47d1
973a0f8
71a4ae9
5afc45a
8ca9b7c
07f1739
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -193,19 +193,143 @@ This is enforced via an extensive and complicated set of enforcements within the | |
- **ISSUE:** The signature walks performed are done with the normal signature walking code. This code is designed to load types as it walks the signature, but in this case the type load functionality is used with the assumption that no type load will actually be triggered. | ||
- **ISSUE:** Stackwalker requirements require support from not just the type system, but also the assembly loader. The Loader has had a number of issues meeting the needs of the type system here. | ||
|
||
Type System and NGEN | ||
-------------------- | ||
|
||
The type system data structures are a core part of what is saved into NGEN images. Unfortunately, these data structures logically have pointers within them that point to other NGEN images. In order to handle this situation, the type system data structures implement a concept known as restoration. | ||
|
||
In restoration, when a type system data structure is first needed, the data structure is fixed up with correct pointers. This is tied into the type loading levels described in the [Type Loader](type-loader.md) Book of the Runtime chapter. | ||
|
||
There also exists the concept of pre-restored data structures. This means that the data structure is sufficiently correct at NGEN image load time (after intra-module pointer fixups and eager load type fixups), that the data structure may be used as is. This optimization requires that the NGEN image be "hard bound" to its dependent assemblies. See NGEN documentation for further details. | ||
|
||
Type System and Domain Neutral Loading | ||
-------------------------------------- | ||
|
||
The type system is a core part of the implementation of domain neutral loading. This is exposed to customers through the LoaderOptimization options available at AppDomain creation. Mscorlib is always loaded as domain neutral. The core requirement of this feature is that the type system data structures must not require pointers to domain specific state. Primarily this manifests itself in requirements around static fields and class constructors. In particular, whether or not a class constructor has been run is not a part of the core MethodTable data structure for this reason, and there is a mechanism for storing static data attached to the DomainFile data structure instead of the MethodTable data structure. | ||
## Static variables | ||
|
||
Static variables in CoreCLR are handled by a combination of getting the "static base", and then adjusting it by an offset to get a pointer to the actual value. | ||
We define the statics base as either non-gc or gc for each field. | ||
Currently non-gc statics are any statics which are represented by primitive types (byte, sbyte, char, int, uint, long, ulong, float, double, pointers of various forms), and enums. | ||
GC statics are any statics which are represented by classes or by non-primitive valuetypes. | ||
For struct statics, the static variable is actually a pointer to a boxed instance of the structure. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see "valuetypes" above but "struct" here. Just want to make sure we are being consistent about the topic. I personally prefer "valuetypes", but "struct" works if that is clearer. |
||
|
||
### Per type static variable information | ||
As of .NET 9, the static variable bases are now all associated with their particular type. | ||
As you can see from this diagram, the data for statics can be acquired by starting at a `MethodTable` and then getting either the `DynamicStaticsInfo` to get a statics pointer, or by getting a `ThreadStaticsInfo` to get a TLSIndex, which then can be used with the thread static variable system to get the actual thread static base. | ||
|
||
```mermaid | ||
classDiagram | ||
MethodTable : MethodTableAuxiliaryData* m_pAuxData | ||
MethodTable --> MethodTableAuxiliaryData | ||
MethodTableAuxiliaryData --> DynamicStaticsInfo : If has static variables | ||
MethodTableAuxiliaryData --> GenericStaticsInfo : If is generic and has static variables | ||
MethodTableAuxiliaryData --> ThreadStaticsInfo : If has thread local static variables | ||
|
||
DynamicStaticsInfo : StaticsPointer m_pGCStatics | ||
DynamicStaticsInfo : StaticsPointer m_pNonGCStatics | ||
|
||
GenericStaticsInfo : FieldDesc* m_pFieldDescs | ||
|
||
ThreadStaticsInfo : TLSIndex NonGCTlsIndex | ||
ThreadStaticsInfo : TLSIndex GCTlsIndex | ||
``` | ||
|
||
```mermaid | ||
classDiagram | ||
|
||
note for StaticsPointer "StaticsPointer is a pointer sized integer" | ||
StaticsPointer : void* PointerToStaticBase | ||
StaticsPointer : bool HasClassConstructorBeenRun | ||
|
||
note for TLSIndex "TLSIndex is a 32bit integer" | ||
TLSIndex : TLSIndexType indexType | ||
TLSIndex : 24bit int indexOffset | ||
``` | ||
|
||
In the above diagram, you can see that we have separate fields for non-gc and gc statics, as well as thread and normal statics. | ||
For normal statics, we use a single pointer sized field, which also happens to encode whether or not the class constructor has been run. | ||
This is done to allow lock free atomic access to both get the static field address as well as determine if the class constructor needs to be triggered. | ||
For TLS statics, handling of detecting whether or not the class constructor has been run is a more complex process described as part of the thread statics infrastructure. | ||
The `DynamicStaticsInfo` and `ThreadStaticsInfo` structures are accessed without any locks, so it is important to ensure that access to fields on these structures can be done with a single memory access, to avoid memory order tearing issues. | ||
|
||
Also, notably, for generic types, each field has a `FieldDesc` which is allocated per type instance, and is not shared by multiple canonical instances. | ||
|
||
#### Lifetime management for collectible statics | ||
|
||
Finally we have a concept of collectible assemblies in the CoreCLR runtime, so we need to handle lifetime management for static variables. | ||
The approach chosen was to build a special GC handle type which will allow the runtime to have a pointer in the runtime data structures to the interior of a managed object on the GC heap. | ||
|
||
The requirement of behavior here is that a static variable cannot keep its own collectible assembly alive, and so collectible statics have the peculiar property that they can exist and be finalized before the collectible assembly is finally collected. | ||
If there is some resurrection scenario, this can lead to very surprising behavior. | ||
|
||
### Thread Statics | ||
|
||
Thread statics are static variables which have a lifetime which is defined to be the shorter of the lifetime of the type containing the static, and the lifetime of the thread on which the static variable is accessed. | ||
They are created by having a static variable on a type which is attributed with `[System.Runtime.CompilerServices.ThreadStaticAttribute]`. | ||
The general scheme of how this works is to assign an "index" to the type which is the same on all threads, and then on each thread hold a data structure which is efficiently accessed by means of this index. | ||
However, we have a few peculiarities in our approach. | ||
|
||
1. We segregate collectible and non-collectible thread statics (`TLSIndexType::NonCollectible` and `TLSIndexType::Collectible`) | ||
2. We provide an ability to share a non-gc thread static between native CoreCLR code and managed code (Subset of `TLSIndexType::DirectOnThreadLocalData`) | ||
3. We provide an extremely efficient means to access a small number of non-gc thread statics. (The rest of the usage of `TLSIndexType::DirectOnThreadLocalData`) | ||
|
||
#### Per-Thread Statics Data structures | ||
```mermaid | ||
classDiagram | ||
|
||
note for ThreadLocalInfo "There is 1 of these per thread, and it is managed by the C++ compiler/OS using standard mechanisms. | ||
It can be found as the t_ThreadStatics variable in a C++ compiler, and is also pointed at by the native Thread class." | ||
ThreadLocalInfo : int cNonCollectibleTlsData | ||
ThreadLocalInfo : void** pNonCollectibleTlsArrayData | ||
ThreadLocalInfo : int cCollectibleTlsData | ||
ThreadLocalInfo : void** pCollectibleTlsArrayData | ||
ThreadLocalInfo : InFlightTLSData *pInFightData | ||
ThreadLocalInfo : Thread* pThread | ||
ThreadLocalInfo : Special Thread Statics Shared Between Native and Managed code | ||
ThreadLocalInfo : byte[N] ExtendedDirectThreadLocalTLSData | ||
|
||
InFlightTLSData : InFlightTLSData* pNext | ||
InFlightTLSData : TLSIndex tlsIndex | ||
InFlightTLSData : OBJECTHANDLE hTLSData | ||
|
||
ThreadLocalInfo --> InFlightTLSData : For TLS statics which have their memory allocated, but have not been accessed since the class finished running its class constructor | ||
InFlightTLSData --> InFlightTLSData : linked list | ||
``` | ||
|
||
#### Access patterns for getting the thread statics address | ||
|
||
This is the pattern that the JIT will use to access a thread static which is not `DirectOnThreadLocalData`. | ||
|
||
0. Get the TLS index somehow | ||
1. Get TLS pointer to OS managed TLS block for the current thread ie. `pThreadLocalData = &t_ThreadStatics` | ||
2. Read 1 integer value `pThreadLocalData->cCollectibleTlsData OR pThreadLocalData->cNonCollectibleTlsData` | ||
3. Compare cTlsData against the index we're looking up `if (cTlsData < index.GetIndexOffset())` | ||
4. If the index is not within range, jump to step 11. | ||
5. Read 1 pointer value from TLS block `pThreadLocalData->pCollectibleTlsArrayData` OR `pThreadLocalData->pNonCollectibleTlsArrayData` | ||
6. Read 1 pointer from within the TLS Array. `pTLSBaseAddress = *(intptr_t*)(((uint8_t*)pTlsArrayData) + index.GetIndexOffset()` | ||
7. If pointer is NULL jump to step 11 `if pTLSBaseAddress == NULL` | ||
8. If TLS index not a Collectible index, return pTLSBaseAddress | ||
9. if `ObjectFromHandle((OBJECTHANDLE)pTLSBaseAddress)` is NULL, jump to step 11 | ||
10. Return `ObjectFromHandle((OBJECTHANDLE)pTLSBaseAddress)` | ||
11. Tail-call a helper `return GetThreadLocalStaticBase(index)` | ||
|
||
This is the pattern that the JIT will use to access a thread static which is on `DirectOnThreadLocalData` | ||
0. Get the TLS index somehow | ||
1. Get TLS pointer to OS managed TLS block for the current thread ie. `pThreadLocalData = &t_ThreadStatics` | ||
2. Add the index offset to the start of the ThreadLocalData structure `pTLSBaseAddress = ((uint8_t*)pThreadLocalData) + index.GetIndexOffset()` | ||
|
||
#### Lifetime management for thread static variables | ||
We distinguish between collectible and non-collectible thread static variables for efficiency purposes. | ||
|
||
A non-collectible thread static is a thread static defined on a type which cannot be collected by the runtime. | ||
This describes most thread statics in actual observed practice. | ||
The `DirectOnThreadLocalData` statics are a subset of this category which has a speical optimized form and does not need any GC reporting. | ||
For non-collectible thread statics, the pointer (`pNonCollectibleTlsArrayData`) in the `ThreadLocalData` is a pointer to a managed `object[]` which points at either `object[]`, `byte[]`, or `double[]` arrays. | ||
At GC scan time, the pointer to the initial object[] is the only detail which needs to be reported to the GC. | ||
|
||
A collectible thread static is a thread static which can be collected by the runtime. | ||
This describes the static variables defined on types which can be collected by the runtime. | ||
The pointer (`pCollectibleTlsArrayData`) in the `ThreadLocalData` is a pointer to a chunk of memory allocated via `malloc`, and holds pointers to `object[]`, `byte[]`, or `double[]` arrays. | ||
At GC scan time, each managed object must individually be kept alive only if the type and thread is still alive. This requires properly handling several situations. | ||
1. If a collectible assembly becomes unreferenced, but a thread static variable associated with it has a finalizer, the object must move to the finalization queue. | ||
2. If a thread static variable associated with a collectible assembly refers to the collectible assembly `LoaderAllocator` via a series of object references, it must not provide a reason for the collectible assembly to be considered referenced. | ||
3. If a collectible assembly is collected, then the associated static variables no longer exist, and the TLSIndex values associated with that collectible assembly becomes re-useable. | ||
4. If a thread is no longer executing, then all thread statics associated with that thread are no longer kept alive. | ||
|
||
The approach chosen is to use a pair of different handle types. | ||
For efficient access, the handle type stored in the dynamically adjusted array is a WeakTrackResurrection GCHandle. | ||
This handle instance is associated with the slot in the TLS data, not with the exact instantiation, so it can be re-used when the if the associated collectible assembly is collected, and then the slot is re-used. | ||
In addition, each slot that is in use will have a `LOADERHANDLE` which will keep the object alive until the `LoaderAllocator` is freed. | ||
This `LOADERHANDLE` will be abandoned if the `LoaderAllocator` is collected, but that's ok, as `LOADERHANDLE` only needs to be cleaned up if the `LoaderAllocator` isn't collected. | ||
On thread destroy, for each collectible slot in the tls array, we will explicitly free the `LOADERHANDLE` on the correct `LoaderAllocator`. | ||
|
||
Physical Architecture | ||
===================== | ||
|
@@ -221,6 +345,7 @@ Major parts of the type system are found in: | |
- Array – Code for handling the special cases required for array processing | ||
- VirtualStubDispatch.cpp/h/inl – Code for virtual stub dispatch | ||
- VirtualCallStubCpu.hpp – Processor specific code for virtual stub dispatch. | ||
- threadstatics.cpp/h - Handling for thread static variables. | ||
|
||
Major entry points are BuildMethodTable, LoadTypeHandleThrowing, CanCastTo\*, GetMethodDescFromMemberDefOrRefOrSpecThrowing, GetFieldDescFromMemberRefThrowing, CompareSigs, and VirtualCallStubManager::ResolveWorkerStatic. | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1715,8 +1715,8 @@ ClrDataAccess::GetModuleData(CLRDATA_ADDRESS addr, struct DacpModuleData *Module | |
ModuleData->bIsReflection = pModule->IsReflection(); | ||
ModuleData->bIsPEFile = pModule->IsPEFile(); | ||
ModuleData->Assembly = HOST_CDADDR(pModule->GetAssembly()); | ||
ModuleData->dwModuleID = pModule->GetModuleID(); | ||
ModuleData->dwModuleIndex = pModule->GetModuleIndex().m_dwIndex; | ||
ModuleData->dwModuleID = 0; // CoreCLR no longer has this concept | ||
ModuleData->dwModuleIndex = 0; // CoreCLR no longer has this concept | ||
ModuleData->dwTransientFlags = pModule->m_dwTransientFlags; | ||
ModuleData->LoaderAllocator = HOST_CDADDR(pModule->m_loaderAllocator); | ||
ModuleData->ThunkHeap = HOST_CDADDR(pModule->m_pThunkHeap); | ||
|
@@ -3246,47 +3246,16 @@ ClrDataAccess::GetNestedExceptionData(CLRDATA_ADDRESS exception, CLRDATA_ADDRESS | |
HRESULT | ||
ClrDataAccess::GetDomainLocalModuleData(CLRDATA_ADDRESS addr, struct DacpDomainLocalModuleData *pLocalModuleData) | ||
{ | ||
if (addr == 0 || pLocalModuleData == NULL) | ||
return E_INVALIDARG; | ||
|
||
SOSDacEnter(); | ||
|
||
DomainLocalModule* pLocalModule = PTR_DomainLocalModule(TO_TADDR(addr)); | ||
|
||
pLocalModuleData->pGCStaticDataStart = TO_CDADDR(PTR_TO_TADDR(pLocalModule->GetPrecomputedGCStaticsBasePointer())); | ||
pLocalModuleData->pNonGCStaticDataStart = TO_CDADDR(pLocalModule->GetPrecomputedNonGCStaticsBasePointer()); | ||
pLocalModuleData->pDynamicClassTable = PTR_CDADDR(pLocalModule->m_pDynamicClassTable.Load()); | ||
pLocalModuleData->pClassData = (TADDR) (PTR_HOST_MEMBER_TADDR(DomainLocalModule, pLocalModule, m_pDataBlob)); | ||
|
||
SOSDacLeave(); | ||
return hr; | ||
// CoreCLR does not use domain local modules anymore | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does this need to come with There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The check/warning message in SOS is only done for commands that assume runtime data structure layout like dumplog, threads -special, printexception. These 2 APIs are called in dumpobj which doesn't do the check and will fail with no warning. It looks like SOS should do the check/warning on every command. I didn't consider these type of API breaking changes just layout changes when I added the checks. I'll add a SOS tracking issue to address this. In the end, yes, SOS_BREAKING_CHANGE_VERSION should be bumped. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Interesting. I had interpreted the failures in !dumpobj as pretty reasonable and not breaking. The way it failed is fairly graceful, as instead of crashing, SOS would simply report There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
It impacts clrmd too.
I think it is hard for a random person out there to connect the dots between SOS failing to dump the statics and needing a newer SOS version to fix that. |
||
return E_NOTIMPL; | ||
} | ||
|
||
|
||
HRESULT | ||
ClrDataAccess::GetDomainLocalModuleDataFromModule(CLRDATA_ADDRESS addr, struct DacpDomainLocalModuleData *pLocalModuleData) | ||
{ | ||
if (addr == 0 || pLocalModuleData == NULL) | ||
return E_INVALIDARG; | ||
|
||
SOSDacEnter(); | ||
|
||
Module* pModule = PTR_Module(TO_TADDR(addr)); | ||
DomainLocalModule* pLocalModule = PTR_DomainLocalModule(pModule->GetDomainLocalModule()); | ||
if (!pLocalModule) | ||
{ | ||
hr = E_INVALIDARG; | ||
} | ||
else | ||
{ | ||
pLocalModuleData->pGCStaticDataStart = TO_CDADDR(PTR_TO_TADDR(pLocalModule->GetPrecomputedGCStaticsBasePointer())); | ||
pLocalModuleData->pNonGCStaticDataStart = TO_CDADDR(pLocalModule->GetPrecomputedNonGCStaticsBasePointer()); | ||
pLocalModuleData->pDynamicClassTable = PTR_CDADDR(pLocalModule->m_pDynamicClassTable.Load()); | ||
pLocalModuleData->pClassData = (TADDR) (PTR_HOST_MEMBER_TADDR(DomainLocalModule, pLocalModule, m_pDataBlob)); | ||
} | ||
|
||
SOSDacLeave(); | ||
return hr; | ||
// CoreCLR does not use domain local modules anymore | ||
return E_NOTIMPL; | ||
} | ||
|
||
HRESULT | ||
|
@@ -3299,31 +3268,8 @@ ClrDataAccess::GetDomainLocalModuleDataFromAppDomain(CLRDATA_ADDRESS appDomainAd | |
HRESULT | ||
ClrDataAccess::GetThreadLocalModuleData(CLRDATA_ADDRESS thread, unsigned int index, struct DacpThreadLocalModuleData *pLocalModuleData) | ||
{ | ||
if (pLocalModuleData == NULL) | ||
return E_INVALIDARG; | ||
|
||
SOSDacEnter(); | ||
|
||
pLocalModuleData->threadAddr = thread; | ||
pLocalModuleData->ModuleIndex = index; | ||
|
||
PTR_Thread pThread = PTR_Thread(TO_TADDR(thread)); | ||
PTR_ThreadLocalBlock pLocalBlock = ThreadStatics::GetCurrentTLB(pThread); | ||
PTR_ThreadLocalModule pLocalModule = pLocalBlock->GetTLMIfExists(ModuleIndex(index)); | ||
if (!pLocalModule) | ||
{ | ||
hr = E_INVALIDARG; | ||
} | ||
else | ||
{ | ||
pLocalModuleData->pGCStaticDataStart = TO_CDADDR(PTR_TO_TADDR(pLocalModule->GetPrecomputedGCStaticsBasePointer())); | ||
pLocalModuleData->pNonGCStaticDataStart = TO_CDADDR(pLocalModule->GetPrecomputedNonGCStaticsBasePointer()); | ||
pLocalModuleData->pDynamicClassTable = PTR_CDADDR(pLocalModule->m_pDynamicClassTable); | ||
pLocalModuleData->pClassData = (TADDR) (PTR_HOST_MEMBER_TADDR(ThreadLocalModule, pLocalModule, m_pDataBlob)); | ||
} | ||
|
||
SOSDacLeave(); | ||
return hr; | ||
// CoreCLR does not use thread local modules anymore | ||
return E_NOTIMPL; | ||
} | ||
|
||
|
||
|
@@ -3656,6 +3602,7 @@ static const char *LoaderAllocatorLoaderHeapNames[] = | |
{ | ||
"LowFrequencyHeap", | ||
"HighFrequencyHeap", | ||
"StaticsHeap", | ||
"StubHeap", | ||
"ExecutableHeap", | ||
"FixupPrecodeHeap", | ||
|
@@ -3690,6 +3637,7 @@ HRESULT ClrDataAccess::GetLoaderAllocatorHeaps(CLRDATA_ADDRESS loaderAllocatorAd | |
int i = 0; | ||
pLoaderHeaps[i++] = HOST_CDADDR(pLoaderAllocator->GetLowFrequencyHeap()); | ||
pLoaderHeaps[i++] = HOST_CDADDR(pLoaderAllocator->GetHighFrequencyHeap()); | ||
pLoaderHeaps[i++] = HOST_CDADDR(pLoaderAllocator->GetStaticsHeap()); | ||
pLoaderHeaps[i++] = HOST_CDADDR(pLoaderAllocator->GetStubHeap()); | ||
pLoaderHeaps[i++] = HOST_CDADDR(pLoaderAllocator->GetExecutableHeap()); | ||
pLoaderHeaps[i++] = HOST_CDADDR(pLoaderAllocator->GetFixupPrecodeHeap()); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does "non-primitive" in this case mean non-enums or non-blittable or some other concept? I assume it isn't the same as C#
unmanaged
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, it's any valuetype which when examined via
GetVerifierCorElementType
will return anCorElementType
which is notELEMENT_TYPE_VALUETYPE
or a pointer type. Effectively, its defined as the set of valuetypes which are not eligible for being a non-gc static.