¿Este objeto-lifetime-extending-closure es un error del compilador C#?
memory-leaks lambda (2)
Eso seguro parece un error. Gracias por llamar mi atención. Lo miraré. Es posible que ya haya sido encontrado y arreglado.
Estaba respondiendo a una question sobre la posibilidad de cierres (legítimamente) que prolongan la duración de los objetos cuando me topé con un código-gen extremadamente curioso por parte del compilador de C # (4.0 si eso importa).
La reproducción más corta que puedo encontrar es la siguiente:
- Cree una lambda que capture un local mientras llama a un método estático del tipo que lo contiene.
- Asigna la referencia delegada generada a un campo de instancia del objeto contenedor.
Resultado: el compilador crea un objeto de cierre que hace referencia al objeto que creó el lambda, cuando no tiene ninguna razón para hacerlo: el destino ''interno'' del delegado es un método estático , y los miembros de instancia del objeto de creación lambda no necesitan ser (y no) tocado cuando se ejecuta el delegado. Efectivamente, el compilador actúa como si el programador lo hubiese captado sin motivo.
class Foo
{
private Action _field;
public void InstanceMethod()
{
var capturedVariable = Math.Pow(42, 1);
_field = () => StaticMethod(capturedVariable);
}
private static void StaticMethod(double arg) { }
}
El código generado de una compilación de lanzamiento (descompilado a ''C'' más simple '') se ve así:
public void InstanceMethod()
{
<>c__DisplayClass1 CS$<>8__locals2 = new <>c__DisplayClass1();
CS$<>8__locals2.<>4__this = this; // What''s this doing here?
CS$<>8__locals2.capturedVariable = Math.Pow(42.0, 1.0);
this._field = new Action(CS$<>8__locals2.<InstanceMethod>b__0);
}
[CompilerGenerated]
private sealed class <>c__DisplayClass1
{
// Fields
public Foo <>4__this; // Never read, only written to.
public double capturedVariable;
// Methods
public void <InstanceMethod>b__0()
{
Foo.StaticMethod(this.capturedVariable);
}
}
Observe que <>4__this
campo del objeto de cierre se rellena con una referencia de objeto pero nunca se lee (no hay motivo).
Entonces, ¿qué está pasando aquí? ¿La especificación del lenguaje lo permite? ¿Es esto un error / rareza del compilador o hay una buena razón (que claramente me falta) para que el cierre haga referencia al objeto? Esto me pone ansioso porque parece una receta para los programadores felices de cerrar (como yo) para introducir inadvertidamente extrañas fugas de memoria (imagine si el delegado se usó como un controlador de eventos) en los programas.
Parece ser un error o innecesario:
Ejecuto tu ejemplo en IL lang:
.method public hidebysig
instance void InstanceMethod () cil managed
{
// Method begins at RVA 0x2074
// Code size 63 (0x3f)
.maxstack 4
.locals init (
[0] class ConsoleApplication1.Program/Foo/''<>c__DisplayClass1'' ''CS$<>8__locals2''
)
IL_0000: newobj instance void ConsoleApplication1.Program/Foo/''<>c__DisplayClass1''::.ctor()
IL_0005: stloc.0
IL_0006: ldloc.0
IL_0007: ldarg.0
IL_0008: stfld class ConsoleApplication1.Program/Foo ConsoleApplication1.Program/Foo/''<>c__DisplayClass1''::''<>4__this'' //Make ref to this
IL_000d: nop
IL_000e: ldloc.0
IL_000f: ldc.r8 42
IL_0018: ldc.r8 1
IL_0021: call float64 [mscorlib]System.Math::Pow(float64, float64)
IL_0026: stfld float64 ConsoleApplication1.Program/Foo/''<>c__DisplayClass1''::capturedVariable
IL_002b: ldarg.0
IL_002c: ldloc.0
IL_002d: ldftn instance void ConsoleApplication1.Program/Foo/''<>c__DisplayClass1''::''<InstanceMethod>b__0''()
IL_0033: newobj instance void [mscorlib]System.Action::.ctor(object, native int)
IL_0038: stfld class [mscorlib]System.Action ConsoleApplication1.Program/Foo::_field
IL_003d: nop
IL_003e: ret
} // end of method Foo::InstanceMethod
Ejemplo 2:
class Program
{
static void Main(string[] args)
{
}
class Foo
{
private Action _field;
public void InstanceMethod()
{
var capturedVariable = Math.Pow(42, 1);
_field = () => Foo2.StaticMethod(capturedVariable); //Foo2
}
private static void StaticMethod(double arg) { }
}
class Foo2
{
internal static void StaticMethod(double arg) { }
}
}
in cl: (¡¡Nota !! ahora la referencia ha desaparecido!)
public hidebysig
instance void InstanceMethod () cil managed
{
// Method begins at RVA 0x2074
// Code size 56 (0x38)
.maxstack 4
.locals init (
[0] class ConsoleApplication1.Program/Foo/''<>c__DisplayClass1'' ''CS$<>8__locals2''
)
IL_0000: newobj instance void ConsoleApplication1.Program/Foo/''<>c__DisplayClass1''::.ctor()
IL_0005: stloc.0
IL_0006: nop //No this pointer
IL_0007: ldloc.0
IL_0008: ldc.r8 42
IL_0011: ldc.r8 1
IL_001a: call float64 [mscorlib]System.Math::Pow(float64, float64)
IL_001f: stfld float64 ConsoleApplication1.Program/Foo/''<>c__DisplayClass1''::capturedVariable
IL_0024: ldarg.0 //No This ref
IL_0025: ldloc.0
IL_0026: ldftn instance void ConsoleApplication1.Program/Foo/''<>c__DisplayClass1''::''<InstanceMethod>b__0''()
IL_002c: newobj instance void [mscorlib]System.Action::.ctor(object, native int)
IL_0031: stfld class [mscorlib]System.Action ConsoleApplication1.Program/Foo::_field
IL_0036: nop
IL_0037: ret
}
Ejemplo 3:
class Program
{
static void Main(string[] args)
{
}
static void Test(double arg)
{
}
class Foo
{
private Action _field;
public void InstanceMethod()
{
var capturedVariable = Math.Pow(42, 1);
_field = () => Test(capturedVariable);
}
private static void StaticMethod(double arg) { }
}
}
en IL: (este puntero está de vuelta)
IL_0006: ldloc.0
IL_0007: ldarg.0
IL_0008: stfld class ConsoleApplication1.Program/Foo ConsoleApplication1.Program/Foo/''<>c__DisplayClass1''::''<>4__this'' //Back again.
Y en los tres casos, el método-b__0 () - tiene el mismo aspecto:
instance void ''<InstanceMethod>b__0'' () cil managed
{
// Method begins at RVA 0x2066
// Code size 13 (0xd)
.maxstack 8
IL_0000: ldarg.0
IL_0001: ldfld float64 ConsoleApplication1.Program/Foo/''<>c__DisplayClass1''::capturedVariable
IL_0006: call void ConsoleApplication1.Program/Foo::StaticMethod(float64) //Your example
IL_0006: call void ConsoleApplication1.Program/Foo2::StaticMethod(float64)//Example 2
IL_0006: call void ConsoleApplication1.Program::Test(float64) //Example 3
IL_000b: nop
IL_000c: ret
}
Y en los 3 casos hay una referencia a un método estático, por lo que es más extraño. Entonces, después de este pequeño análisis, diré que es un error / para nada bueno. !