Erro potencial do .NET JIT?

O código a seguir fornece uma saída diferente ao executar a versão dentro do Visual Studio e ao exterior do Visual Studio. Estou usando o Visual Studio 2008 e direcionando o .NET 3.5. Eu também tentei o .NET 3.5 SP1.

Quando executado fora do Visual Studio, o JIT deve entrar em ação. (A) há algo sutil acontecendo com o C # que estou ausente ou (b) o JIT está realmente com erro. Duvido que o JIT possa dar errado, mas estou ficando sem outras possibilidades ...

Saída ao executar dentro do Visual Studio:

    0 0,
    0 1,
    1 0,
    1 1,

Saída ao executar a versão fora do Visual Studio:

    0 2,
    0 2,
    1 2,
    1 2,

Qual é a razão?

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Test
{
    struct IntVec
    {
        public int x;
        public int y;
    }

    interface IDoSomething
    {
        void Do(IntVec o);
    }

    class DoSomething : IDoSomething
    {
        public void Do(IntVec o)
        {
            Console.WriteLine(o.x.ToString() + " " + o.y.ToString()+",");
        }
    }

    class Program
    {
        static void Test(IDoSomething oDoesSomething)
        {
            IntVec oVec = new IntVec();
            for (oVec.x = 0; oVec.x < 2; oVec.x++)
            {
                for (oVec.y = 0; oVec.y < 2; oVec.y++)
                {
                    oDoesSomething.Do(oVec);
                }
            }
        }

        static void Main(string[] args)
        {
            Test(new DoSomething());
            Console.ReadLine();
        }
    }
}

É um bug do otimizador JIT. Ele está desenrolando o loop interno, mas não atualizando o valor oVec.y corretamente:

      for (oVec.x = 0; oVec.x < 2; oVec.x++) {
0000000a  xor         esi,esi                         ; oVec.x = 0
        for (oVec.y = 0; oVec.y < 2; oVec.y++) {
0000000c  mov         edi,2                           ; oVec.y = 2, WRONG!
          oDoesSomething.Do(oVec);
00000011  push        edi  
00000012  push        esi  
00000013  mov         ecx,ebx 
00000015  call        dword ptr ds:[00170210h]        ; first unrolled call
0000001b  push        edi                             ; WRONG! does not increment oVec.y
0000001c  push        esi  
0000001d  mov         ecx,ebx 
0000001f  call        dword ptr ds:[00170210h]        ; second unrolled call
      for (oVec.x = 0; oVec.x < 2; oVec.x++) {
00000025  inc         esi  
00000026  cmp         esi,2 
00000029  jl          0000000C 

O bug desaparece quando você deixa oVec.y aumentar para 4, são muitas chamadas para desenrolar.

Uma solução alternativa é esta:

  for (int x = 0; x < 2; x++) {
    for (int y = 0; y < 2; y++) {
      oDoesSomething.Do(new IntVec(x, y));
    }
  }

UPDATE: verificado novamente em agosto de 2012, esse bug foi corrigido no jitter da versão 4.0.30319. Mas ainda está presente no jitter da v2.0.50727. Parece improvável que eles consertem isso na versão antiga depois de tanto tempo.

Eu acredito que isso esteja ocorrendo em um bug de compilação JIT genuíno. Eu reportaria à Microsoft e veria o que eles dizem. Curiosamente, descobri que o x64 JIT não tem o mesmo problema.

Aqui está minha leitura do x86 JIT.

// save context
00000000  push        ebp  
00000001  mov         ebp,esp 
00000003  push        edi  
00000004  push        esi  
00000005  push        ebx  

// put oDoesSomething pointer in ebx
00000006  mov         ebx,ecx 

// zero out edi, this will store oVec.y
00000008  xor         edi,edi 

// zero out esi, this will store oVec.x
0000000a  xor         esi,esi 

// NOTE: the inner loop is unrolled here.
// set oVec.y to 2
0000000c  mov         edi,2 

// call oDoesSomething.Do(oVec) -- y is always 2!?!
00000011  push        edi  
00000012  push        esi  
00000013  mov         ecx,ebx 
00000015  call        dword ptr ds:[002F0010h] 

// call oDoesSomething.Do(oVec) -- y is always 2?!?!
0000001b  push        edi  
0000001c  push        esi  
0000001d  mov         ecx,ebx 
0000001f  call        dword ptr ds:[002F0010h] 

// increment oVec.x
00000025  inc         esi  

// loop back to 0000000C if oVec.x < 2
00000026  cmp         esi,2 
00000029  jl          0000000C 

// restore context and return
0000002b  pop         ebx  
0000002c  pop         esi  
0000002d  pop         edi  
0000002e  pop         ebp  
0000002f  ret     

Parece uma otimização ruim para mim ...

Copiei seu código em um novo aplicativo de console.

• Compilação de depuração
  • Saída correta com depurador e sem depurador
• Comutado para compilar versão
  • Novamente, corrija a saída nas duas vezes
• Criou uma nova configuração x86 (estou executando o X64 Windows 2008 e estava usando 'Qualquer CPU')
• Compilação de depuração
  • Obteve a saída correta F5 e CTRL + F5
• Release Build
  • Saída correta com o depurador conectado
  • Sem depurador - Obteve a saída incorreta

Portanto, é o xIT JIT que gera incorretamente o código. Excluí meu texto original sobre a reordenação de loops etc. Algumas outras respostas aqui confirmaram que o JIT está desenrolando o loop incorretamente quando está no x86.

Para corrigir o problema, você pode alterar a declaração do IntVec para uma classe e funciona em todos os tipos.

Acho que isso precisa continuar no MS Connect ....

-1 para a Microsoft!