¿Cómo funcionan los cierres detrás de escena? (C#)

Question

Creo que tengo una comprensión bastante decente de los cierres, cómo usarlos y cuándo pueden ser útiles. Pero lo que no entiendo es cómo funcionan realmente detrás de escena en la memoria. Un código de ejemplo:

public Action Counter() 
{ 
    int count = 0; 
    Action counter =() => 
    { 
     count++; 
    }; 

    return counter; 
} 

Normalmente, si {count} no fue capturado por el cierre, su ciclo de vida sería como alcance el método Contador(), y después de que se complete se iría con el resto de la pila asignación para Counter(). ¿Qué sucede cuando está cerrado? ¿La asignación de la pila completa para esta llamada de Counter() se mantiene? ¿Copia {count} al montón? ¿Realmente nunca se asigna en la pila, pero el compilador lo reconoce como cerrado y, por lo tanto, siempre vive en el montón?

Para esta pregunta en particular, estoy interesado principalmente en cómo funciona esto en C#, pero no me opondría a las comparaciones con otros lenguajes que admiten cierres.

Answer 1

El compilador (a diferencia del tiempo de ejecución) crea otra clase/tipo. La función con su cierre y las variables que cerró/izó/capturó se vuelven a escribir a lo largo de su código como miembros de esa clase. Un cierre en .Net se implementa como una instancia de esta clase oculta.

Eso significa que su variable de conteo es un miembro de una clase diferente por completo, y la vida útil de esa clase funciona como cualquier otro objeto clr; no es elegible para la recolección de basura hasta que ya no esté rooteado. Eso significa que siempre que tengas una referencia invocable al método no irá a ninguna parte.

Answer 2

Su tercera suposición es correcta. El compilador generará un código como este:

private class Locals 
{ 
    public int count; 
    public void Anonymous() 
    { 
    this.count++; 
    } 
} 

public Action Counter() 
{ 
    Locals locals = new Locals(); 
    locals.count = 0; 
    Action counter = new Action(locals.Anonymous); 
    return counter; 
} 

¿Tiene sentido?

Además, ha pedido comparaciones. VB y JScript crean cierres de la misma manera.

Answer 3

Gracias @HenkHolterman. Como Eric ya lo explicó, agregué el enlace solo para mostrar qué clase real genera el compilador para el cierre. Me gustaría agregar que la creación de clases de visualización mediante el compilador de C# puede provocar pérdidas de memoria. Por ejemplo, dentro de una función hay una variable int que es capturada por una expresión lambda y hay otra variable local que simplemente contiene una referencia a una matriz de bytes grande. El compilador crearía una instancia de clase de pantalla que contendrá las referencias a ambas variables, es decir, int y la matriz de bytes. Pero la matriz de bytes no será recogida de basura hasta que se haga referencia a la lambda.

Answer 4

La respuesta de Eric Lippert realmente llega al punto. Sin embargo, sería bueno construir una imagen de cómo funcionan los marcos de pila y las capturas en general. Hacer esto ayuda a mirar un ejemplo un poco más complejo.

Aquí es el código de captura:

public class Scorekeeper { 
    int swish = 7; 

    public Action Counter(int start) 
    { 
     int count = 0; 
     Action counter =() => { count += start + swish; } 
     return counter; 
    } 
} 

Y aquí es lo que yo creo que el equivalente sería (si tenemos suerte Eric Lippert comentarios sobre si esto es realmente correcto o no):

private class Locals 
{ 
    public Locals(Scorekeeper sk, int st) 
    { 
     this.scorekeeper = sk; 
     this.start = st; 
    } 

    private Scorekeeper scorekeeper; 
    private int start; 

    public int count; 

    public void Anonymous() 
    { 
    this.count += start + scorekeeper.swish; 
    } 
} 

public class Scorekeeper { 
    int swish = 7; 

    public Action Counter(int start) 
    { 
     Locals locals = new Locals(this, start); 
     locals.count = 0; 
     Action counter = new Action(locals.Anonymous); 
     return counter; 
    } 
} 

El punto es que la clase local sustituye a todo el marco de pila y se inicializa en consecuencia cada vez que se invoca el método de Contador. Normalmente, el marco de pila incluye una referencia a 'esto', más argumentos de método, más variables locales. (El marco de pila también se extiende cuando se ingresa un bloque de control.)

En consecuencia, no tenemos un solo objeto que corresponda al contexto capturado, sino que tenemos un objeto por marco de pila capturado.

En base a esto, podemos usar el siguiente modelo mental: los marcos de pila se mantienen en el montón (en lugar de en la pila), mientras que la pila solo contiene punteros a los marcos de pila que están en el montón. Los métodos Lambda contienen un puntero al marco de la pila. Esto se hace utilizando la memoria administrada, por lo que el marco se queda en el montón hasta que ya no se necesita.

Obviamente, el compilador puede implementar esto utilizando solo el montón cuando se requiere el objeto Heap para admitir un cierre lambda.

Lo que me gusta de este modelo es que proporciona una imagen integrada para 'rendimiento de retorno'. Podemos pensar en un método de iterador (utilizando retorno de rendimiento) como si fuera un marco de pila creado en el montón y el puntero de referencia almacenado en una variable local en el llamador, para usarlo durante la iteración.