search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
14.98k stars 4.66k forks source link

[Question] LoadContext and NI files #49605

Open alpencolt opened 3 years ago

alpencolt commented 3 years ago

According to https://github.com/dotnet/runtime/blob/3553284bea7b650874c8dcc3f78d6be085a047bb/docs/design/features/assemblyloadcontext.md#constraints:

If an attempt is made to load a Ready-To-Run (R2R) image from the same location in multiple load context's, then precompiled code can only be used from the first image that got loaded. The subsequent images will have their code JITted. This happens because subsequent loading binaries from the same location results in OS mapping them to the same memory as the previous one was mapped to and thus, could corrupt internal state information required for use precompiled code.

Native images will be ignored if DLL was loaded to non default context. Could you clarify why loading NI or sharing in process can corrupt runtime?

cc @jkotas @gbalykov

dotnet-issue-labeler[bot] commented 3 years ago

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

jkotas commented 3 years ago

Each load context has its own copy of statics and may contain different versions of dependencies. The fixups in the R2R images point to statics and dependencies within specific context. They are not able to switch based on the load context.

For the same reason, each load context has its own copy of JITed code.

OS mapping them to the same memory as the previous one was mapped to

This is Windows specific behavior. On Windows, we are using OS loader to load R2R images and the OS loader does not allow one image to be loaded multiple times at different addresses. This limitation is not really there on non-Windows platforms since we have a custom loader there.