.net - Método de alineación a través de imágenes nativas de ensamblajes

.net-assembly ngen

Question

Como se explicó en otra pregunta , a Ngen generalmente solo se le permite incluir métodos en línea a través de ensamblajes si el método tiene el conjunto TargetedPatchingOptOutAttribute .

Pero, ¿es esto cierto también para los ensamblajes de unión dura utilizando el LoadHint.Always DependencyAttribute con LoadHint.Always ?

edit: Tal vez la respuesta a mi pregunta inicial sea no, de lo contrario no tendría sentido que el TargetedPatchingOptOutAttribute se use en mscorlib ya que este ensamblaje siempre está enlazado (tiene el conjunto DefaultDependencyAttribute ). Así que me gustaría reformular mi pregunta: ¿Es el TargetedPatchingOptOutAttribute la única forma de obtener un método en línea en las imágenes nativas de ensamblajes?

Answer 1

Parece que esa otra pregunta me llevó a una suposición completamente errónea. Los métodos en nuestros propios ensamblajes están en línea a través de los límites de la imagen nativa, incluso si no tienen límite fijo ni tienen establecido el TargetedPatchingOptOutAttribute . Este atributo solo afecta a los ensamblados de .NET Framework.

Una publicación de blog de Microsoft tiene una sección bastante buena sobre el TargetedPatchingOptOutAttribute :

"Parches dirigidos: el método carece de TargetedPatchingOptOutAttribute": esto se relaciona con una nueva característica en CLR 4 donde las imágenes NGEN son más resistentes a las versiones. En pocas palabras, esperamos poder aplicar un parche o solución a mscorlib.dll y no tener que volver a compilar todas las otras imágenes nativas en la máquina que dependen de ella. Esto solo debería aplicarse a los métodos en las bibliotecas de clase de .NET framework porque son los únicos ensamblajes que pueden optar por esta característica.

Esto significa que: como los ensamblados de .NET Framework ahora admiten parches dirigidos en .NET 4.0, los métodos de esos ensamblajes generalmente no se pueden insertar. Pero los métodos que están marcados con TargetedPatchingOptOutAttribute son críticos para el rendimiento y, por lo tanto, optan por excluirse de la aplicación de parches (lo que significa que si se cambian, todas las imágenes nativas que usan ese método deben volver a compilarse). Dado que nuestros propios ensamblajes no utilizan parches dirigidos, no hay razón para evitar que el método se incorpore en las imágenes nativas.

Para probar esto, creé una pequeña muestra que muestra la pila de llamadas de una excepción lanzada en un ensamblaje diferente. Solo mi método principal y el método que lanzó la excepción estaban en la pila de llamadas. Algunos otros métodos pequeños colocados tanto en el conjunto llamado como en el ensamblado (que básicamente no hacen más que llamar al siguiente método) no estaban en la pila de llamadas. Este comportamiento no cambió después de crear imágenes nativas para los ensamblajes (sí, verifiqué que se usaron las imágenes nativas).

Versión de TLDR: no importa el TargetedPatchingOptOutAttribute , solo se debe usar en los ensamblados de .NET Framework. El método de integración de ensamblajes de desarrollo propio funciona igual con Ngen y JIT.