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)