Remove DomainAssembly and other multi-appdomain dead code (#126881)

Closes #104590

* Deletes DomainAssembly, simplifying DacDbi APIs in the process
* Updates comments and docs mentioning domain-neutral assemblies or
multiple AppDomains
* Removes dead code in dbi & DacDbi related to multiple AppDomains
* Remove IsAssemblyFullyTrusted
* Tested on diagnosticstests

Author: rcj1

docs/design/coreclr/botr/dac-notes.md

@@ -62,7 +62,7 @@ An example may be helpful in understanding how marshaling works. The common debu
 
 The debugger in this figure could be Visual Studio, MDbg, WinDbg, etc. The debugger interfaces with the CLR debugger interface (DBI) APIs to get the information it needs. Information that must come from the target goes through the DAC. The debugger implements the data target, which is responsible for implementing a `ReadVirtual` function to read memory in the target. The dotted line in the diagram represents the process boundary.
 
-Suppose the debugger needs to display the starting address of an ngen'ed method in the managed application that it has gotten from the managed stack. We will assume that the debugger has already gotten an instance of `ICorDebugFunction` back from the DBI. It will begin by calling the DBI API `ICorDebugFunction::GetNativeCode`. This calls into the DAC through the DAC/DBI interface function `GetNativeCodeInfo`, passing in the domain file and metadata token for the function. The following code fragment is a simplification of the actual function, but it illustrates marshaling without introducing extraneous details.
+Suppose the debugger needs to display the starting address of an ngen'ed method in the managed application that it has gotten from the managed stack. We will assume that the debugger has already gotten an instance of `ICorDebugFunction` back from the DBI. It will begin by calling the DBI API `ICorDebugFunction::GetNativeCode`. This calls into the DAC through the DAC/DBI interface function `GetNativeCodeInfo`, passing in the assembly and metadata token for the function. The following code fragment is a simplification of the actual function, but it illustrates marshaling without introducing extraneous details.
 
 	void DacDbiInterfaceImpl::GetNativeCodeInfo(TADDR taddrDomainFile,
 	            mdToken functionToken,

docs/design/coreclr/botr/profiling.md

@@ -118,7 +118,7 @@ A ProcessID is unique system-wide for the lifetime of the process. All other IDs
 
 ### Hierarchy & Containment
 
-ID's are arranged in a hierarchy, mirroring the hierarchy in the process. Processes contain AppDomains contain Assemblies contain Modules contain Classes contain Functions. Threads are contained within Processes, and may move from AppDomain to AppDomain. Objects are mostly contained within AppDomains (a very few objects may be members of more than one AppDomain at a time). Contexts are contained within Processes.
+ID's are arranged in a hierarchy, mirroring the hierarchy in the process. Processes contain the global AppDomain which contains Assemblies which contain Modules which contain Classes which contain Functions. Threads are contained within Processes. Objects are contained within the AppDomain. Contexts are contained within Processes.
 
 ### Lifetime & Stability
 
@@ -140,12 +140,6 @@ GCHandleID – Alive from the call to HandleCreated until the return from Handle
 
 In addition, any ID returned from a profiling API function will be alive at the time it is returned.
 
-### App-Domain Affinity
-
-There is an AppDomainID for each user-created app-domain in the process, plus the "default" domain, plus a special pseudo-domain used for holding domain-neutral assemblies.
-
-Assembly, Module, Class, Function, and GCHandleIDs have app-domain affinity, meaning that if an assembly is loaded into multiple app domains, it (and all of the modules, classes, and functions contained within it) will have a different ID in each, and operations upon each ID will take effect only in the associated app domain. Domain-neutral assemblies will appear in the special pseudo-domain mentioned above.
-
 ### Special Notes
 
 All IDs except ObjectID should be treated as opaque values. Most IDs are fairly self-explanatory. A few are worth explaining in more detail:
@@ -386,8 +380,8 @@ There are four types of statics. The following table describes what they are and
 
 | **Static Type** | **Definition** | **Identifying in Metadata** |
 | --------------- | -------------- | --------------------------- |
-| AppDomain       | Your basic static field—has a different value in each app domain. | Static field with no attached custom attributes |
-| Thread          | Managed TLS—a static field with a unique value for each thread and each app domain. | Static field with System.ThreadStaticAttribute |
+| AppDomain       | Your basic static field. | Static field with no attached custom attributes |
+| Thread          | Managed TLS—a static field with a unique value for each thread. | Static field with System.ThreadStaticAttribute |
 | RVA             | Process-scoped static field with a home in the module's data section | Static field with hasRVA flag |
 | Context         | Static field with a different value in each COM+ Context | Static field with System.ContextStaticAttribute |
 

docs/design/coreclr/botr/threading.md

@@ -18,7 +18,7 @@ The public Thread interface available to managed code intentionally hides the de
 
 The CLR provides equivalent abstractions for managed threads, implemented by the CLR itself. For example, it does not expose the operating system's thread-local storage (TLS) mechanism, but instead provides managed "thread-static" variables. Similarly, it does not expose the native thread's "thread ID," but instead provides a "managed thread ID" which is generated independently of the OS. However, for diagnostic purposes, some details of the underlying native thread may be obtained via types in the System.Diagnostics namespace.
 
-Managed threads require additional functionality typically not needed by native threads. First, managed threads hold GC references on their stacks, so the CLR must be able to enumerate (and possibly modify) these references every time a GC occurs. To do this, the CLR must "suspend" each managed thread (stop it at a point where all of its GC references can be found).  Second, when an AppDomain is unloaded, the CLR must ensure that no thread is executing code in that AppDomain. This requires the ability to force a thread to unwind out of that AppDomain. The CLR does this by injecting a ThreadAbortException into such threads.
+Managed threads require additional functionality typically not needed by native threads. First, managed threads hold GC references on their stacks, so the CLR must be able to enumerate (and possibly modify) these references every time a GC occurs. To do this, the CLR must "suspend" each managed thread (stop it at a point where all of its GC references can be found).  Second, when the AppDomain is unloaded, the CLR must ensure that no thread is executing code in the AppDomain. This requires the ability to force a thread to unwind out of the AppDomain. The CLR does this by injecting a ThreadAbortException into such threads.
 
 Data Structures
 ===============
@@ -107,19 +107,6 @@ Hijacking for GC suspension is done by Thread::SysSuspendForGC. This method atte
   * If fully interruptible, it is safe to perform a GC at any point, since the thread is, by definition, at a safe point. It is reasonable to leave the thread suspended at this point (because it's safe) but various historical OS bugs prevent this from working, because the CONTEXT retrieved earlier may be corrupt. Instead, the thread's instruction pointer is overwritten, redirecting it to a stub that will capture a more complete CONTEXT, leave cooperative mode, wait for the GC to complete, reenter cooperative mode, and restore the thread to its previous state.
   * If partially-interruptible, the thread is, by definition, not at a safe point. However, the caller will be at a safe point (method transition). Using that knowledge, the CLR "hijacks" the top-most stack frame's return address (physically overwrite that location on the stack) with a stub similar to the one used for fully-interruptible code. When the method returns, it will no longer return to its actual caller, but rather to the stub (the method may also perform a GC poll, inserted by the JIT, before that point, which will cause it to leave cooperative mode and undo the hijack).
 
-ThreadAbort / AppDomain-Unload
-==============================
-
-In order to unload an AppDomain, the CLR must ensure that no thread is running in that AppDomain. To accomplish this, all managed threads are enumerated, and "abort" any threads which have stack frames belonging to the AppDomain being unloaded. A ThreadAbortException is "injected" into the running thread, which  causes the thread to unwind (executing backout code along the way) until it is no longer executing in the AppDomain, at which point the ThreadAbortException is translated into an AppDomainUnloaded exception.
-
-ThreadAbortException is a special type of exception. It can be caught by user code, but the CLR ensures that the exception will be rethrown after the user's exception handler is executed. Thus ThreadAbortException is sometimes referred to as "uncatchable," though this is not strictly true.
-
-A ThreadAbortException is typically 'thrown' by simply setting a bit on the managed thread marking it as "aborting." This bit is checked by various parts of the CLR (most notably, every return from a p/invoke) and often times setting this bit is all that is needed to get the thread aborted in a timely manner.
-
-However, if the thread is, for example, executing a long-running managed loop, it may never check this bit. To get such a thread to abort faster, the thread is "hijacked" and forced to raise a ThreadAbortException. This hijacking is done in the same way as GC suspension, except that the stubs that the thread is redirected to will cause a ThreadAbortException to be raised, rather than waiting for a GC to complete.
-
-This hijacking means that a ThreadAbortException can be raised at essentially any arbitrary point in managed code. This makes it extremely difficult for managed code to deal successfully with a ThreadAbortException. It is therefore unwise to use this mechanism for any purpose other than AppDomain-Unload, which ensures that any state corrupted by the ThreadAbort will be cleaned up along with the AppDomain.
-
 Synchronization: Managed
 ========================
 

docs/design/datacontracts/Loader.md

@@ -32,7 +32,7 @@ public enum AssemblyIterationFlags
     IncludeLoading = 0x00000002, // include assemblies that are still in the process of loading
                                  // (all m_level values)
     IncludeAvailableToProfilers = 0x00000020, // include assemblies available to profilers
-                                              // See comment at code:DomainAssembly::IsAvailableToProfilers
+                                              // See comment at code:Assembly::IsAvailableToProfilers
 
     // Execution / introspection flags
     IncludeExecution = 0x00000004, // include assemblies that are loaded for execution only
@@ -166,7 +166,7 @@ enum ClrModifiableAssemblies : uint
 | `CGrowableSymbolStream` | `Buffer` | Pointer to the raw symbol stream buffer start |
 | `CGrowableSymbolStream` | `Size` | Size of the raw symbol stream buffer |
 | `AppDomain` | `RootAssembly` | Pointer to the root assembly |
-| `AppDomain` | `DomainAssemblyList` | ArrayListBase of assemblies in the AppDomain |
+| `AppDomain` | `AssemblyList` | ArrayListBase of assemblies in the AppDomain |
 | `AppDomain` | `FriendlyName` | Friendly name of the AppDomain |
 | `SystemDomain` | `GlobalLoaderAllocator` | global LoaderAllocator |
 | `SystemDomain` | `SystemAssembly` | pointer to the system Assembly |
@@ -272,13 +272,10 @@ IEnumerable<ModuleHandle> GetModuleHandles(TargetPointer appDomain, AssemblyIter
 
     // ArrayListBase encapsulates the data structure defined in arraylist.h
     // It handles reading each contained pointer and exposing them as a C# List
-    ArrayListBase arrayList = // read ArrayListBase starting at appDomain + AppDomain::DomainAssemblyList offset
+    ArrayListBase arrayList = // read ArrayListBase starting at appDomain + AppDomain::AssemblyList offset
 
-    foreach (TargetPointer domainAssembly in arrayList.Elements)
+    foreach (TargetPointer pAssembly in arrayList.Elements)
     {
-        // We have a list of DomainAssemblies, this class contains a single pointer to an Assembly.
-        // Therefore we can read a pointer at the DomainAssembly to access the actual Assembly.
-        TargetPointer pAssembly = target.ReadPointer(domainAssembly);
         Assembly assembly = // read Assembly object at pAssembly
 
         // The Assemblies map 1:1 to Modules, however we must filter them based on the iterationFlags before returning.
@@ -345,8 +342,7 @@ IEnumerable<ModuleHandle> GetModuleHandles(TargetPointer appDomain, AssemblyIter
             if (((ModuleFlags)module.Flags).HasFlag(ModuleFlags.Tenured))
             {
                 // Un-tenured collectible assemblies should not be returned. (This can only happen in a brief
-                // window during collectible assembly creation. No thread should need to have a pointer
-                // to the just allocated DomainAssembly at this stage.)
+                // window during collectible assembly creation.
                 // the assemblies Module is not Tenured, skip
                 continue;
             }

docs/design/features/code-versioning.md

@@ -286,31 +286,6 @@ Another interesting consideration is that in the future I anticipate having some
 
 Thus if the current implementation doesn't appear ideal partly this may be because I wasn't sufficiently clever, but the other part is that I was optimizing for future conditions.
 
-### Domains ###
-There is one CodeVersionManager per AppDomain, and one for the SharedDomain. Versioning for a given method always looks up the appropriate CodeVersionManager by traversing from MethodDef token -> Module that defines that token -> Domain that loaded that module -> CodeVersionManager. In code this is either:
-
-```
-Module* pModule;
-pModule->GetDomain()->GetCodeVersionManager()
-MethodDesc* pMethod;
-pMethod->GetModule()->GetDomain()->GetCodeVersionManager()
-```
-
-Some shortcut accessors are defined to make these lookups simpler:
-
-```
-pModule->GetCodeVersionManager()
-pMethod->GetCodeVersionManager()
-```
-
-Generics can cause methods in domain-neutral modules to refer to types in domain-specific modules. The rules above dictate that these code versions still reside in the domain-neutral CodeVersionManager. The AppDomain specific CodeVersionManagers will never contain code versions with a domain-neutral type in their instantiation.
-
-CoreCLR is largely moving away from multiple AppDomains but I left the domain distinctions in place for a few reasons:
-
-1. Pragmatically the feature is a partial refactoring of ReJitManager and this is what ReJitManager did. Diverging from ReJitManager's design incurs extra time and risk of new issues.
-2. Maybe someday we will want to migrate similar functionality back to the desktop .NET SKU. Desktop supports multiple AppDomains so per-AppDomain handling would be required in that context.
-
-AppDomain unloading however has not been handled. If CoreCLR supports proper AppDomain unload at some point or the code moves back to desktop runtime we will need to handle this gap.
 
 ### Code activation and publishing ###
 
@@ -332,7 +307,7 @@ In order to do step 3 the `CodeVersionManager` relies on one of three different
 ### Thread-safety ###
 CodeVersionManager is designed for use in a free-threaded environment, in many cases by requiring the caller to acquire a lock before calling. This lock can be acquired by constructing an instance of `CodeVersionManager::LockHolder`.
 
-in some scope for the CodeVersionManager being operated on. CodeVersionManagers from different domains should not have their locks taken by the same thread with one exception, it is OK to take the shared domain  manager lock and one AppDomain manager lock in that order. The lock is required to change the shape of the tree or traverse it but not to read/write configuration properties from each node. A few special cases:
+in some scope for the CodeVersionManager being operated on. The lock is required to change the shape of the tree or traverse it but not to read/write configuration properties from each node. A few special cases:
 
 - CodeVersionManager::SetActiveILCodeVersions needs to operate partially inside and partially outside the lock. The caller should not acquire the lock beforehand.
 - NativeCodeVersion::GetILCodeVersion() does not require the lock if the caller first guarantees it is operating on the default code version.