跨程序集本机映像内联的方法 [英] Method inlining across native images of assemblies

问题描述

如另一个问题所述，如果方法具有 TargetedPatchingOptOutAttribute 设置.>

但是对于 硬绑定也是如此吗? 程序集使用 DependencyAttribute 与 LoadHint.Always?

也许我最初的问题的答案是否定的，否则在 mscorlib 中使用 TargetedPatchingOptOutAttribute 是没有意义的，因为该程序集始终是硬绑定的(它有 DefaultDependencyAttribute 设置).所以我想重新表述我的问题:TargetedPatchingOptOutAttribute 是在程序集的本机映像中内联方法的唯一方法吗?

解决方案

看起来是这样的 其他问题 让我做出了一个完全错误的假设.我们自己的程序集中的方法跨本机图像边界内联，即使它们既没有硬绑定也没有设置TargetedPatchingOptOutAttribute.此属性仅影响 .NET Framework 程序集.

Microsoft 的博客文章有一个关于 TargetedPatchingOptOutAttribute 的很好的部分:

<块引用>

"Targeted Patching - 方法缺少 TargetedPatchingOptOutAttribute" -这与 CLR 4 中的一项新功能有关，其中 NGEN 图像更多版本有弹性.简而言之，我们希望能够应用补丁或修复 mscorlib.dll 而不必重新编译所有其他本机依赖它的机器上的图像.这应该只适用于.NET 框架类库中的方法，因为它们是只有可以选择加入此功能的程序集.

这意味着:因为 .NET Framework 程序集现在支持 目标修补 在 .NET 4.0 中，这些程序集中的方法通常无法内联.但是用 TargetedPatchingOptOutAttribute 标记的方法对性能至关重要，因此选择退出目标修补(这意味着如果它们被更改，所有使用该方法的本机映像都需要重新编译).由于我们自己的程序集不使用有针对性的修补，因此没有理由阻止跨原生图像的方法内联.

为了测试这一点，我创建了一个小示例，显示了在不同程序集中引发的异常的调用堆栈.只有我的 main 方法和抛出异常的方法在调用堆栈中.调用和被调用程序集中的其他一些小方法(基本上只做调用下一个方法)不在调用堆栈中.在为程序集创建本机映像后，此行为没有改变(是的，我检查了是否使用了本机映像).

TLDR 版本:不要关心 TargetedPatchingOptOutAttribute，它应该只在 .NET Framework 程序集中使用.自行开发的程序集的方法内联与 Ngen 和 JIT 的工作原理相同.

As explained in another question, Ngen is usually only allowed to inline methods across assemblies if the method has the TargetedPatchingOptOutAttribute set.

But is this also true for hard bound assemblies by using the DependencyAttribute with LoadHint.Always?

edit: Maybe the answer to my initial question is no, otherwise it would make no sense that the TargetedPatchingOptOutAttribute is used in mscorlib since this assembly is always hard bound (it has the DefaultDependencyAttribute set). So I'd like to rephrase my question: Is the TargetedPatchingOptOutAttribute the only way to get a method inlined across native images of assemblies?

解决方案

It seems like that other question led me to a completely wrong assumption. Methods in our own assemblies are inlined across native image boundries, even if they are neither hard bound nor have the TargetedPatchingOptOutAttribute set. This attribute only affects the .NET Framework assemblies.

A Microsoft blog post has a quite good section about the TargetedPatchingOptOutAttribute:

"Targeted Patching - Method lacks TargetedPatchingOptOutAttribute" - this relates to a new feature in CLR 4 where NGEN images are more version resilient. In a nutshell, we hope to be able to apply a patch or fix to mscorlib.dll and not have to recompile all the other native images on the machine that depend upon it. This should only apply to methods in the .NET framework class libraries because they are the only assemblies that can opt into this feature.

This means: Because .NET Framework assemblies now support targeted patching in .NET 4.0, methods from those assemblies usually can't be inlined. But methods that are marked with the TargetedPatchingOptOutAttribute are performance critical and therefore opt out of the targeted patching (which means if they are ever changed, all native images that use that method need to be recompiled). Since our own assemblis don't use targeted patching, there is no reason to prevent method inlining across native images.

To test this I created a small sample that shows the call stack of an exception thrown in a different assembly. Only my main method and the method that throwed the exception were in the call stack. Some other small methods placed in both the calling and called assembly (that do basically nothing more than calling the next method) were not in the call stack. This behavior didn't change after creating native images for the assemblies (yes, I checked that the native images were used).

TLDR version: Don't care about the TargetedPatchingOptOutAttribute, it should only be used in the .NET Framework assemblies. Method inlining of self developed assemblies works the same with Ngen and JIT.

这篇关于跨程序集本机映像内联的方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！