At least according to a description of Mono’s exception handling implementation, all the x86 registers are saved when an exception is thrown. Besides the stack pointer (ESP), frame pointers (EBP), instruction pointers (EIP), and the register that holds the exception object, why are the other registers saved as well? Why save that the entire context when in .NET is there is no mechanism to continuing executing at the point immediately after a throw?
UPDATE:
EMCA states the following in section 12.3.2.4 Overview of exception handling:
-
An exception object describing the exception is automatically created by the CLI and pushed onto
the evaluation stack as the first item upon entry of a filter or catch clause. -
Execution cannot be resumed at the location of the exception, except with a filter handler.
I don’t know how the “except with a filter handler” can be accomplished in light of the previous statement. Also the description of the endfilter opcode only has two outcomes: “continue searching for another exception handler” or to execute the handler (which would execute another block of CIL opcodes.) It’s missing a “resume” option. Therefore, I interpret this discrepancy in the specification to basically mean .NET does not support continuing executing at the point immediately after a throw. Maybe it was considered at some point but never fully realized and implemented.
UPDATE 2:
Someone pointed out that “resume” could simply happen if no filter handler opts to catch the exception. However, the specification for throw states: “the throw instruction throws the exception object on the stack and empties the stack.” The emptying of the stack would make it impossible to execute the code immediately after the throw statement, as that code might require something on the stack.
You’re looking at implementation details: they usually aren’t a one to one match to the ECMA spec for many possible reasons (like ease of implementation, code sharing, providing additional semantics, future-proofing, optimizations etc).
In this particular case there are several considerations.
Mono performs exception handling based on a view of the processor state called MonoContext: as this structure is used also in other places, it contains all the relevant registers even if some may not be needed in some particular cases. In particular, exception handling can be initiated also from a cpu exception where all the registers need to be restored, so all of them are collected.
Someone already observed that the context is used also for the debugger.
Consider also the case of a method with a try/catch with the catch being a simple local var setting. Now, an advanced register allocator might put a local var that is used both before the throw (note the throw may be implicit, like a null reference, so handled by the cpu exception path) and after the catch in a register like edx. If you don’t save all the registers at the throw/exception point you corrupted the program state as edx would get overwritten during exception handling.
As a last comment: are you worried that saving the few extra registers is wasting cpu cycles? If you actually count the cycles spent, they are completely in the noise wrt all the stuff that needs to happen during exception handling.