una - Stackoverflow haciendo boxeo en C#

system stackoverflowexception vb net

Question

Tengo estos dos trozos de código en C #:

primero

class Program
{
    static Stack<int> S = new Stack<int>();

    static int Foo(int n) {
        if (n == 0)
            return 0;
        S.Push(0);
        S.Push(1);
        ...
        S.Push(999);
        return Foo( n-1 );
    }
}

Segundo

class Program
{
    static Stack S = new Stack();

    static int Foo(int n) {
        if (n == 0)
            return 0;
        S.Push(0);
        S.Push(1);
        ...
        S.Push(999);
        return Foo( n-1 );
    }
}

Ambos hacen lo mismo:

1. Cree una pila (genérica en <int> para el primer ejemplo y una pila de objeto para el segundo).

2. Declare un método que se llama a sí mismo recursivamente n veces (n> = 0) y en cada paso, introduzca 1000 enteros dentro de la pila creada.

Cuando ejecuto el primer ejemplo con Foo(30000) no se produce ninguna excepción, sin embargo, el segundo ejemplo falla con Foo(1000) , solo n = 1000.

Cuando vi el CIL generado para ambos casos, la única diferencia era la parte del boxeo por cada empuje:

primero

IL_0030:  ldsfld     class [System]System.Collections.Generic.Stack`1<int32> Test.Program::S
IL_0035:  ldc.i4     0x3e7
IL_003a:  callvirt   instance void class [System]System.Collections.Generic.Stack`1<int32>::Push(!0)
IL_003f:  nop

Segundo

IL_003a:  ldsfld     class [mscorlib]System.Collections.Stack Test.Program::S
IL_003f:  ldc.i4     0x3e7
IL_0044:  box        [mscorlib]System.Int32
IL_0049:  callvirt   instance void [mscorlib]System.Collections.Stack::Push(object)
IL_004e:  nop

Mi pregunta es: ¿Por qué, si no hay una sobrecarga significativa de la pila de CIL para el segundo ejemplo, se bloquea "más rápido" que el primero?

Answer 1

¿Por qué, si no hay una sobrecarga significativa de la pila de CIL para el segundo ejemplo, se bloquea "más rápido" que el primero?

Tenga en cuenta que la cantidad de instrucciones CIL no representa con precisión la cantidad de trabajo o memoria que se utilizará. Una sola instrucción puede tener un impacto muy bajo o un impacto muy alto, por lo que contar las instrucciones CIL no es una forma precisa de medir el "trabajo".

También se dan cuenta de que el CIL no es lo que se ejecuta. El JIT compila el CIL a las instrucciones de la máquina real, con una fase de optimización, por lo que el CIL puede ser muy diferente a las instrucciones ejecutadas reales.

En el segundo caso, ya que está utilizando una colección no genérica, cada llamada Push requiere que el entero esté en una casilla, como determinó en CIL.

El boxeo de un entero crea efectivamente un objeto que "envuelve" el Int32 para usted. En lugar de simplemente cargar un entero de 32 bits en la pila, ahora tiene que cargar un entero de 32 bits en la pila, luego encuadrarlo, lo que efectivamente también carga una referencia de objeto en la pila.

Si lo inspecciona en la ventana de Desmontaje, puede ver que la diferencia entre la versión genérica y no genérica es dramática, y mucho más significativa de lo que sugiere el CIL generado.

La versión genérica se compila efectivamente como una serie de llamadas como tal:

0000022c  nop 
            S.Push(25);
0000022d  mov         ecx,dword ptr ds:[03834978h] 
00000233  mov         edx,19h 
00000238  cmp         dword ptr [ecx],ecx 
0000023a  call        71618DD0 
0000023f  nop 
            S.Push(26);
00000240  mov         ecx,dword ptr ds:[03834978h] 
00000246  mov         edx,1Ah 
0000024b  cmp         dword ptr [ecx],ecx 
0000024d  call        71618DD0 
00000252  nop 
            S.Push(27);

El no genérico, por otro lado, tiene que crear los objetos en caja, y en su lugar compila para:

00000645  nop 
            S.Push(25);
00000646  mov         ecx,7326560Ch 
0000064b  call        FAAC20B0 
00000650  mov         dword ptr [ebp-48h],eax 
00000653  mov         eax,dword ptr ds:[03AF4978h] 
00000658  mov         dword ptr [ebp+FFFFFEE8h],eax 
0000065e  mov         eax,dword ptr [ebp-48h] 
00000661  mov         dword ptr [eax+4],19h 
00000668  mov         eax,dword ptr [ebp-48h] 
0000066b  mov         dword ptr [ebp+FFFFFEE4h],eax 
00000671  mov         ecx,dword ptr [ebp+FFFFFEE8h] 
00000677  mov         edx,dword ptr [ebp+FFFFFEE4h] 
0000067d  mov         eax,dword ptr [ecx] 
0000067f  mov         eax,dword ptr [eax+2Ch] 
00000682  call        dword ptr [eax+18h] 
00000685  nop 
            S.Push(26);
00000686  mov         ecx,7326560Ch 
0000068b  call        FAAC20B0 
00000690  mov         dword ptr [ebp-48h],eax 
00000693  mov         eax,dword ptr ds:[03AF4978h] 
00000698  mov         dword ptr [ebp+FFFFFEE0h],eax 
0000069e  mov         eax,dword ptr [ebp-48h] 
000006a1  mov         dword ptr [eax+4],1Ah 
000006a8  mov         eax,dword ptr [ebp-48h] 
000006ab  mov         dword ptr [ebp+FFFFFEDCh],eax 
000006b1  mov         ecx,dword ptr [ebp+FFFFFEE0h] 
000006b7  mov         edx,dword ptr [ebp+FFFFFEDCh] 
000006bd  mov         eax,dword ptr [ecx] 
000006bf  mov         eax,dword ptr [eax+2Ch] 
000006c2  call        dword ptr [eax+18h] 
000006c5  nop 

Aquí se puede ver el significado del boxeo.

En su caso, boxear el número entero hace que las referencias de objetos en caja se carguen en la pila. En mi sistema, esto está provocando un flujo de pila en cualquier llamada más grande que Foo(127) (en 32 bits), lo que sugiere que los números enteros y las referencias de objetos en caja (4 bytes cada uno) se mantienen en la pila, como 127 * 1000 * 8 == 1016000, que está peligrosamente cerca del tamaño predeterminado de pila de subprocesos de 1 MB para aplicaciones .NET.

Cuando se usa la versión genérica, ya que no hay ningún objeto en caja, los enteros no tienen que estar todos almacenados en la pila y se está reutilizando el mismo registro. Esto le permite recibir una cantidad significativamente mayor (> 40000 en mi sistema) antes de usar la pila.

Tenga en cuenta que esto dependerá de la versión CLR y de la plataforma, ya que también hay un JIT diferente en x86 / x64.