Runtime changes for IJW Activation #22636
Conversation
jkoritzinsky
requested review from
jkotas,
vitek-karas and
AaronRobinsonMSFT
src/System.Private.CoreLib/src/Internal/Runtime/InteropServices/ComponentLoadContext.cs
Outdated
Show resolved
Hide resolved
src/System.Private.CoreLib/src/Internal/Runtime/InteropServices/InMemoryAssemblyLoader.cs
Outdated
Show resolved
Hide resolved
|
Any tests we want to add for the native-activation path we'll likely want to do in core-setup since the ijwhost code is the interesting code there. Additionally, those tests will most likely have to wait until we have a compiler that can allow us to link IJW assemblies with ijwhost instead of mscoree. I did some manual testing locally, but I had to manually edit the compiled binary to point to ijwhost instead of mscoree. I have some ideas though on how to test the new System.Private.CoreLib entrypoints within coreclr. I'll get those done next week. |
src/System.Private.CoreLib/src/Internal/Runtime/InteropServices/InMemoryAssemblyLoader.cs
Outdated
Show resolved
Hide resolved
src/System.Private.CoreLib/src/Internal/Runtime/InteropServices/IsolatedComponentLoadContext.cs
Show resolved
Hide resolved
src/System.Private.CoreLib/src/System/Runtime/Loader/AssemblyLoadContext.cs
Outdated
Show resolved
Hide resolved
|
@dotnet-bot test this please |
|
This PR is looking awfully weird and including all kind of changes. I think you need to rebase your changes on top of what is checked in, rather than merging in. |
…replicate all of the startup behavior.
…or vtable entries.
…d components into separate ALCs when loaded from native.
… need the module to be loaded to at least FILE_LOAD_DELIVER_EVENTS when resolving dependencies loaded via VTableFixups, otherwise they try to load into the default ALC.
|
@dotnet-bot test this please |
|
@dotnet-bot test OSX10.12 x64 Checked Innerloop Build and Test |
|
@vitek-karas @AaronRobinsonMSFT can you take another review pass when you have a chance? |
|
@AaronRobinsonMSFT @vitek-karas @jkotas anyone have any issues/feedback on what I'm doing in this PR? I'd like to get this merged soon if possible. |
|
@dotnet-bot test Ubuntu x64 Checked CoreFX Tests |
src/System.Private.CoreLib/src/Internal/Runtime/InteropServices/IsolatedComponentLoadContext.cs
Outdated
Show resolved
Hide resolved
src/System.Private.CoreLib/src/Internal/Runtime/InteropServices/InMemoryAssemblyLoader.cs
Show resolved
Hide resolved
src/System.Private.CoreLib/src/System/Runtime/Loader/AssemblyLoadContext.CoreCLR.cs
Show resolved
Hide resolved
src/System.Private.CoreLib/src/Internal/Runtime/InteropServices/InMemoryAssemblyLoader.cs
Outdated
Show resolved
Hide resolved
src/System.Private.CoreLib/src/Internal/Runtime/InteropServices/InMemoryAssemblyLoader.cs
Show resolved
Hide resolved
|
The two failures are infra failures due to their flow jobs still being created even after being deleted. So I'm going to merge this in since everything else passed. |
* Implement loading an assembly from an HMODULE on Windows. * Use the native runtime to execute the main method so I don't have to replicate all of the startup behavior. * If ijwhost is loaded, then call back into ijwhost to resolve tokens for vtable entries. * Refactor our various component loaders (COM and IJW) and have IJW load components into separate ALCs when loaded from native. * Move VTableFixups after DeliverSyncEvents in our incremental load. We need the module to be loaded to at least FILE_LOAD_DELIVER_EVENTS when resolving dependencies loaded via VTableFixups, otherwise they try to load into the default ALC. * Only try to get ijwhost module handle on Windows. * Use defined() instead of ifndef * Fix off-Windows build break and fix unvalid comment. * ComponentLoadContext->IsolatedComponentLoadContext * Only build InMemoryAssemblyLoader when targeting windows. * Add doc comments for IsolatedComponentLoadContext. * Rename qcall. * Add comment for boolean parameter. * Add null check for managed ExecuteMainMethod entrypoint. * Add comments in ceeload.cpp for the ijwhost method resolution. * Add test verifying runtime callback to IJW host. * Add test for InMemoryAssemblyLoader.LoadInMemoryAssembly. * Fix x86 behavior rel. loading symbols by name and stdcall mangling. * Remove exe entrypoints. The executable case for mixed-mode will go through the normal .NET Core app model (no special hosting support needed). * Clean up whitespace * Add test verifying M->N->M ALC switch behavior with IJW. * Resolve the ijwhost module by probing the PE for the IJW assembly instead of hardcoding the name. * Remove static caching in GetTokenGetterFromHostModule. * Disable new IJW tests on Win7. * PR Feedback. * Cleanup extra copy of function. * Use old-style environment checking in LoadIjwFromModuleHandle since we reference S.P.CL directly. * Fix break in rebase * Clean up fake mscoree code. * Only validate that a CLR header exists. The OS verifies everything else. * Make ijw host resolution code static to ceeload.cpp * Use bracketed include for xplatform.h * Update comment on _CorDllMain * PR feedback. * Remove .def file. * PR feedback. * Verify we export correctly on x86 and x64. * Fix path to ijwhostmock for CopyConstructorMarshaler * Disable IJW tests on arm32 nightly. Can't repro the dependency load failures. Fixes dotnet/coreclr#23358 Commit migrated from dotnet/coreclr@ea10aac
Add managed entry-points for loading IJW exes and dlls into the runtime.
When resolving tokens in the vtfixup table, call into the ijwhost (if loaded) to resolve delayed-activation thunks back to tokens if needed.
Change the ordering of incremental loading to make DeliverSyncEvents happen before VTableFixups. This change was needed because the IJW assembly needs to be loaded enough to have assemblies it loads assign it as their parent. This requires the IJW assembly to be loaded at least through DeliverSyncEvents when loading dependent assemblies. Dependent assembly loading can happen while running VTableFixups, so either VTableFixups has to happen after DeliverSyncEvents, or the requirement for an assembly to be considered "loaded" (not "active") must be a load level before VTableFixups.
If the IJW assembly is not considered "loaded", then dependent assemblies fall back to loading into the default ALC, which will fail because of the assembly isolation we want for components.
cc: @jeffschwMSFT @sdmaclea
Contributes to #18013
See dotnet/core-setup#5185 for the hosting component.