How does the .NET VM check for integer overflows?

Question

As we all know and love .NET does throw an IntegerOverflow exception every time an integer overflows. I think this is a very good thing.

But I wonder how they make this fast. x86 does not trap on integer overflows and I would be surprised if other architectures would allow one to do that. The best solution I have found for x86 is to put an "INTO" instruction after every single arithmetic operation. But I assume that would result in a noticeable slowdown.

They could do some static checking in the compiler to avoid this in cases when it can be proofed that the operation can not overflow. But what about performance critical inner loops when the compiler can't determine the outcome of the operations?

I tried to look at the Mono source but I couldn't find the spot where they do these checks.

So does anyone have a clue what they really do? I really would like to know.

On a side note: Is there a way to see the x86 code the .NET JITC emits?

Answer 1

It throws only if you are within a checked context, either in the source or as a setting in the project (this is language dependent). The result of which is to out put a different IL instruction.

This is just a specific example of the general problem of arithmetic overflow and the x86 JIT implementation will doubtless insert a check of the relevant flags after any such operation with an instruction to throw an exception if the flags are set.

the instructions (using addition as an example) are:

• add to add two numbers (with wrap around overflow)
• add.ovf to add two numbers and trap signed overflow
• add.ovf.un to add two numbers and trap unsigned overflow

There is indeed a certain level of compiler verification in that constant folding occurs and the resulting value must fit in the assigned variable. Other static analysis measures are possible but there are limits to what can be trapped.

If you wish to see the emitted JIT code simply debug the relevant code in mixed mode and take a look at the disassembly, stack, registers as you would a normal program. Alternatively go and take a look in the ngen images (this is tricky as the format is susceptible to change).

Note that doing this via VS, you may wish to start the program as normal (in Release mode), then attach the debugger since the result of the JIT is different depending on whether a debugger is attached and whether the assembly is marked as disallowing optimizations (the default for debug builds)

Answer 2

Start debugging, right-click source, Go To Disassembly. You'd see something like this:

      int ix = int.MaxValue;
0000003a  mov         dword ptr [ebp-40h],7FFFFFFFh 
      int jx = 1;
00000041  mov         dword ptr [ebp-44h],1 
      Console.WriteLine(ix + jx);
00000048  mov         ecx,dword ptr [ebp-40h] 
0000004b  add         ecx,dword ptr [ebp-44h] 
0000004e  jno         00000055                 <--- overflow test
00000050  call        6D7ABAD2                 <--- kaboom
00000055  call        6CFE2F40 

In other words: the JIT compiler generates explicit code to check for overflows. This is off by default.