| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
from crossing ALCs (#21606)
* Create repro for dotnet/coreclr#19654
* Update ICustomMarshaler.csproj
* Update ICustomMarshaler.csproj
* Clean up repro per feedback.
* Add test case for different assemblies with the same CustomMarshaler name.
* Move EEMarshalingData cache from AppDomain to LoaderAllocator. This fixes the custom-marshaler conflict when using unloadable assembly contexts.
* Internalize the LoaderHeap* parameter.
* Add the pointer to the requesting assembly to the hashtable key.
* Fix linux-musl build break.
* Move Crst out of FEATURE_COMINTEROP block.
* Make sure to copy over the assembly pointer to the key that's actually stored in the hash table.
* Add comment for m_invokingAssembly.
* Move all usages of EEMarshallingData to hang off the correct loader allocator instead of always the global one.
* Change to m_InteropDataCrst since this EEMarshallingData can be used in preemptive GC mode.
* Always init m_InteropDataCrst (since it's used by EEMarshallingData as well as COM).
* PR Feedback.
* Remove extraneous inlines.
|
|
Patch vtable slots and similar when tiering is enabled
For a method eligible for code versioning and vtable slot backpatch:
- It does not have a precode (`HasPrecode()` returns false)
- It does not have a stable entry point (`HasStableEntryPoint()` returns false)
- A call to the method may be:
- An indirect call through the `MethodTable`'s backpatchable vtable slot
- A direct call to a backpatchable `FuncPtrStub`, perhaps through a `JumpStub`
- For interface methods, an indirect call through the virtual stub dispatch (VSD) indirection cell to a backpatchable `DispatchStub` or a `ResolveStub` that refers to a backpatchable `ResolveCacheEntry`
- The purpose is that typical calls to the method have no additional overhead when code versioning is enabled
Recording and backpatching slots:
- In order for all vtable slots for the method to be backpatchable:
- A vtable slot initially points to the `MethodDesc`'s temporary entry point, even when the method is inherited by a derived type (the slot's value is not copied from the parent)
- The temporary entry point always points to the prestub and is never backpatched, in order to be able to discover new vtable slots through which the method may be called
- The prestub, as part of `DoBackpatch()`, records any slots that are transitioned from the temporary entry point to the method's at-the-time current, non-prestub entry point
- Any further changes to the method's entry point cause recorded slots to be backpatched in `BackpatchEntryPointSlots()`
- In order for the `FuncPtrStub` to be backpatchable:
- After the `FuncPtrStub` is created and exposed, it is patched to point to the method's at-the-time current entry point if necessary
- Any further changes to the method's entry point cause the `FuncPtrStub` to be backpatched in `BackpatchEntryPointSlots()`
- In order for VSD entities to be backpatchable:
- A `DispatchStub`'s entry point target is aligned and recorded for backpatching in `BackpatchEntryPointSlots()`
- The `DispatchStub` was modified on x86 and x64 such that the entry point target is aligned to a pointer to make it backpatchable
- A `ResolveCacheEntry`'s entry point target is recorded for backpatching in `BackpatchEntryPointSlots()`
Slot lifetime and management of recorded slots:
- A slot is recorded in the `LoaderAllocator` in which the slot is allocated, see `RecordAndBackpatchEntryPointSlot()`
- An inherited slot that has a shorter lifetime than the `MethodDesc`, when recorded, needs to be accessible by the `MethodDesc` for backpatching, so the dependent `LoaderAllocator` with the slot to backpatch is also recorded in the `MethodDesc`'s `LoaderAllocator`, see `MethodDescBackpatchInfo::AddDependentLoaderAllocator_Locked()`
- At the end of a `LoaderAllocator`'s lifetime, the `LoaderAllocator` is unregistered from dependency `LoaderAllocators`, see `MethodDescBackpatchInfoTracker::ClearDependencyMethodDescEntryPointSlots()`
- When a `MethodDesc`'s entry point changes, backpatching also includes iterating over recorded dependent `LoaderAllocators` to backpatch the relevant slots recorded there, see `BackpatchEntryPointSlots()`
Synchronization between entry point changes and backpatching slots
- A global lock is used to ensure that all recorded backpatchable slots corresponding to a `MethodDesc` point to the same entry point, see `DoBackpatch()` and `BackpatchEntryPointSlots()` for examples
Due to startup time perf issues:
- `IsEligibleForTieredCompilation()` is called more frequently with this change and in hotter paths. I chose to use a `MethodDesc` flag to store that information for fast retreival. The flag is initialized by `DetermineAndSetIsEligibleForTieredCompilation()`.
- Initially, I experimented with allowing a method versionable with vtable slot backpatch to have a precode, and allocated a new precode that would also be the stable entry point when a direct call is necessary. That also allows recording a new slot to be optional - in the event of an OOM, the slot may just point to the stable entry point. There are a large number of such methods and the allocations were slowing down startup perf. So, I had to eliminate precodes for methods versionable with vtable slot backpatch and that in turn means that recording slots is necessary for versionability.
|
|
* Remove IsNeutralDomain()
* PR feedback
|
|
* Enable COM interop for collectible classes
* Modify DispatchInfo to use LoaderAllocator handles
The DispatchMemberInfo was using global handles to refer to the managed
MemberInfo instances. That doesn't work with unloadability.
This change modifies it to use handles allocated from LoaderAllocator.
* Disable COM interop for WinRT types
* Remove collectible check from IsTypeVisibleFromCom. That fixes three
new COM interop tests
* Add collectible check to GetComClassFactory when we check for
unsupported interop with WinRT
* Add COM unloadability tests
Add two tests to test COM unloadability:
* One for using native COM server from managed COM client
* One for using managed COM objects from native client
* Add unloading test for IUnknownTest
* Disable NETClientPrimitivesInALC on Win ARM
The NETClientPrimitives is disabled there too.
|
|
|
|
The ILStubCache was being allocated per domain unless the domain was a
compilation AppDomain. This is wrong for collectible assemblies, since
after an assembly is collected, the cache keeps stale entries referring
to already deleted MethodTables.
The fix is to make ILStubChange per LoaderAllocator instead (and keep
the per module instances for compilation AppDomain).
|
|
|
|
* Fix collectible NativeCallable UMThunkEntry lifetime
The UMEntryThunk cache entries created for NativeCallable target methods
for collectible classes were not properly cleaned up at the unload time.
This change fixes that by adding UMEntryThunkCache on LoaderAllocator
and using it for entries belonging to NativeCallable targets on
collectible classes. The cache is created lazily.
* Reflect PR feedback
Remove the UMEntryThunk cache from the AppDomain and leave it just on
the LoaderAllocator.
|
|
* Enable thread statics for collectible classes
This change removes checks that were preventing usage of thread statics
in collectible classes and also implements all the necessary changes.
The handles that hold arrays with thread statics are allocated from
LoaderAllocator for collectible classes instead of using the global
strong handle like in the case of non-collectible classes.
The change very much mimics what is done for regular statics.
This change also adds ability to reuse freed handles to the
LoaderAllocator handle table. Freed handle indexes are stored into a
stack and when a new handle allocation is requested, the indices from
this stack are used first.
Due to the code path from which the FreeTLM that in turn frees the
handles is called, I had to modify the critical section flags and also
refactor the handle allocation so that the actual managed array
representing the handle table is allocated out of the critical section.
When I was touching the code, I have also moved the code that was
dealing with handles that are not stored in the LoaderAllocator handle
tables out of the critical section, since there is no point in having it
inside of it.
|
|
Enable assembly unloading
* Allow PInvoke methods on collectible assemblies
* Fix test unloadability
Several hundreds of tests were using Helper class that created
GCHandle, but never freed it. That prevented unloading of those
tests. The change modifies the Helper class to keep the handle
in a finalizable object.
Several GCHandle related tests were not freeing the GCHandle they
allocated, so this change adds freeing them to enable the unloading.
* Add missing error messages to the resources
* Fix shuffle thunk cache for unloadability
* Add GetLoaderAllocator to ICLRPrivBinder
|
|
This makes tiered compilation work properly with profiler ReJIT, and positions the runtime to integrate other versioning related features together in the future. See the newly added code-versioning design-doc in this commit for more information.
Breaking changes for profilers: See code-versioning-profiler-breaking-changes.md for more details.
|
|
|
|
|
|
- Crossgen is now built as part of coreclr
- Crossgen successfully compiles mscorlib.dll
- Resulting mscorlib.ni.dll not yet usable
|
|
[tfs-changeset: 1407945]
|
