【问题标题】:.NET 3.5 JIT not working when running the application.NET 3.5 JIT 在运行应用程序时不起作用
【发布时间】:2011-01-04 15:27:23
【问题描述】:

以下代码在 Visual Studio 内运行版本和在 Visual Studio 外运行版本时给出不同的输出。我正在使用 Visual Studio 2008 并以 .NET 3.5 为目标。我也尝试过 .NET 3.5 SP1。

在 Visual Studio 外部运行时,JIT 应该启动。要么 (a) 我遗漏了 C# 的一些微妙之处,要么 (b) JIT 实际上有错误。我怀疑 JIT 是否会出错,但我已经没有其他可能性了......

在 Visual Studio 中运行时的输出:

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

在 Visual Studio 之外运行发布时的输出:

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

是什么原因?

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();
        }
    }
}

【问题讨论】:

  • 是的 - 怎么样:在 .Net JIT 这样重要的东西中发现一个严重的错误 - 恭喜!
  • 这似乎在我 12 月 9 日构建的 x86 4.0 框架中重现。我会把它传递给 jitter 团队。谢谢!
  • 这是真正值得获得金牌徽章的极少数问题之一。
  • 我们都对这个问题感兴趣的事实表明,我们不期望 .NET JIT 中的错误,微软干得好。
  • 我们都在焦急地等待微软的回复.....

标签: c# .net-3.5 jit


【解决方案1】:

这是一个 JIT 优化器错误。它正在展开内部循环,但没有正确更新 oVec.y 值:

      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 

当您让 oVec.y 增加到 4 时,该错误就会消失,这对于展开的调用太多了。

一种解决方法是:

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

更新:2012 年 8 月重新检查,此错误已在版本 4.0.30319 抖动中修复。但仍然存在于 v2.0.50727 抖动中。过了这么久,他们似乎不太可能在旧版本中修复这个问题。

【讨论】:

  • +1,绝对是一个错误 - 我可能已经确定了错误的条件(不是说 nobugz 是因为我才发现它的!),但是这个(还有你的,尼克,所以 +1也适合你)表明 JIT 是罪魁祸首。有趣的是,当 IntVec 被声明为一个类时,优化要么被删除,要么不同。即使您在循环之前先将结构字段显式初始化为 0,也会看到相同的行为。讨厌!
  • @Hans Passant 你用什么工具输出汇编代码?
  • @Joan - 只是 Visual Studio,从调试器的反汇编窗口复制/粘贴并手动添加 cmets。
【解决方案2】:

我相信这是一个真正的 JIT 编译错误。我会把它报告给微软,看看他们怎么说。有趣的是,我发现 x64 JIT 没有同样的问题。

这是我对 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     

这对我来说似乎是一个优化问题......

【讨论】:

    【解决方案3】:

    我将您的代码复制到了一个新的控制台应用程序中。

    • 调试构建
      • 使用调试器和不使用调试器的正确输出
    • 切换到发布版本
      • 再次,两次正确输出
    • 创建了一个新的 x86 配置(我正在运行 X64 Windows 2008 并且使用的是“任何 CPU”)
    • 调试构建
      • F5 和 CTRL+F5 都得到了正确的输出
    • 发布版本
      • 附加调试器的正确输出
      • 没有调试器 - 得到不正确的输出

    所以是 x86 JIT 错误地生成了代码。已删除我关于循环重新排序等的原始文本。此处的其他一些答案已确认 JIT 在 x86 上错误地展开循环。

    要解决此问题,您可以将 IntVec 的声明更改为一个类,它适用于所有风格。

    认为这需要在 MS Connect 上继续......

    -1 微软!

    【讨论】:

    • 有趣的想法,但如果是这种情况,这肯定不是“优化”而是编译器中的一个非常重要的错误?现在应该已经找到了吧?
    • 我同意你的看法。像这样重新排序循环可能会导致无法解决的问题。实际上这似乎更不可能,因为 for 循环永远无法达到 2。
    • 看起来像这些讨厌的海森虫之一:P
    • 如果 OP(或使用他的应用程序的任何人)拥有 32 位 x86 机器,则任何 CPU 都将无法工作。问题是启用优化的 x86 JIT 会生成错误代码。
    猜你喜欢
    • 2011-05-20
    • 2011-08-10
    • 1970-01-01
    • 2010-12-10
    • 2016-03-14
    • 2012-04-15
    • 1970-01-01
    • 1970-01-01
    • 2011-03-18
    相关资源
    最近更新 更多