Use a sorted module order for metadata generation #96007
Conversation
The reflection metadata generation within the compiler follows a simple algorithm: foreach module in compilation, for each type in the module, if the type generates metadata, generate metadata for it. But it turns out the list of modules that we start with is not sorted. This is not a problem for multithreaded stability, because none of this happens in the multithreaded phase, but it is a problem for delta patching - small change in a program can perturb the metadata blob for no good reason. This sorts the list.
|
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas Issue DetailsThe reflection metadata generation within the compiler follows a simple algorithm: foreach module in compilation, for each type in the module, if the type generates metadata, generate metadata for it. But it turns out the list of modules that we start with is not sorted. This is not a problem for multithreaded stability, because none of this happens in the multithreaded phase, but it is a problem for delta patching - small change in a program can perturb the metadata blob for no good reason. This sorts the list. Cc @dotnet/ilc-contrib
|
|
/backport to release/8.0-staging |
|
Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/7260181153 |
2 participants
The reflection metadata generation within the compiler follows a simple algorithm: foreach module in compilation, for each type in the module, if the type generates metadata, generate metadata for it. But it turns out the list of modules that we start with is not sorted. This is not a problem for multithreaded stability, because none of this happens in the multithreaded phase, but it is a problem for delta patching - small change in a program can perturb the metadata blob for no good reason.
This sorts the list.
Cc @dotnet/ilc-contrib