This is the first post of a series I am making on C++ exceptions.
When people say "C++ exceptions are slow", what they really meant is that throwing an exception in C++ is slow. C++'s exception handling has zero-cost when there are no exceptions. Let's look at a very simple example.
class Foo {
public:
~Foo() {}
};
class Bar {
public:
~Bar() {}
};
void func(bool b) {
Bar bar{}; // <--- Bar::~Bar() should be called on stack unwinding
if (b) {
throw 1;
}
}
int main() {
try {
Foo foo{}; // <--- Foo::~Foo() should be called on stack unwinding
func(false);
} catch (...) {
}
return 0;
}
I put throw 1; in the code, even though it never throws; so we can see the generated machine code (compiled on clang 13 with -std=c++17 without optimization). Here's the assembly (in Intel syntax), which we will read one piece at a time.
func(bool): # @func(bool)
push rbp
mov rbp, rsp
sub rsp, 32
mov al, dil
and al, 1
mov byte ptr [rbp - 1], al
test byte ptr [rbp - 1], 1
je .LBB0_3
mov edi, 4
call __cxa_allocate_exception
mov rdi, rax
mov dword ptr [rdi], 1
mov esi, offset typeinfo for int
xor eax, eax
mov edx, eax
call __cxa_throw
jmp .LBB0_5
mov rcx, rax
mov eax, edx
mov qword ptr [rbp - 16], rcx
mov dword ptr [rbp - 20], eax
lea rdi, [rbp - 8]
call Bar::~Bar() [base object destructor]
jmp .LBB0_4
.LBB0_3:
lea rdi, [rbp - 8]
call Bar::~Bar() [base object destructor]
add rsp, 32
pop rbp
ret
.LBB0_4:
mov rdi, qword ptr [rbp - 16]
call _Unwind_Resume@PLT
.LBB0_5:
Bar::~Bar() [base object destructor]: # @Bar::~Bar() [base object destructor]
push rbp
mov rbp, rsp
mov qword ptr [rbp - 8], rdi
pop rbp
ret
main: # @main
push rbp
mov rbp, rsp
sub rsp, 32
mov dword ptr [rbp - 4], 0
xor edi, edi
call func(bool)
jmp .LBB2_1
.LBB2_1:
lea rdi, [rbp - 8]
call Foo::~Foo() [base object destructor]
jmp .LBB2_4
mov rcx, rax
mov eax, edx
mov qword ptr [rbp - 16], rcx
mov dword ptr [rbp - 20], eax
lea rdi, [rbp - 8]
call Foo::~Foo() [base object destructor]
mov rdi, qword ptr [rbp - 16]
call __cxa_begin_catch
call __cxa_end_catch
.LBB2_4:
xor eax, eax
add rsp, 32
pop rbp
ret
Foo::~Foo() [base object destructor]: # @Foo::~Foo() [base object destructor]
push rbp
mov rbp, rsp
mov qword ptr [rbp - 8], rdi
pop rbp
ret
Zero-cost exception handling
Let's start from the simplest ones.
.LBB0_5:
Bar::~Bar() [base object destructor]: # @Bar::~Bar() [base object destructor]
push rbp # store the caller frame pointer on stack
mov rbp, rsp # set the frame pointer for the callee
mov qword ptr [rbp - 8], rdi # store `this` pointer on stack (passed in by DRI, dictated by AMD64 ABI)
pop rbp # restore the frame pointer
ret
Both .LBB0_5 and Bar::~Bar() symbols store the code for Bar::~Bar(). We see the common prologue and epilogue on x86.The code is the same for Foo::~Foo(). Now let's take a look at func.
func(bool): # @func(bool)
push rbp
mov rbp, rsp
sub rsp, 32
mov al, dil # dil is the lower 8 bits from RDI(http://www.tortall.net/projects/yasm/manual/html/arch-x86-registers.html) Here, it's passing the `bool` param to AL
and al, 1
mov byte ptr [rbp - 1], al
test byte ptr [rbp - 1], 1
je .LBB0_3 # jump to .LBB0_3 if `b` is not 1/true
mov edi, 4
call __cxa_allocate_exception
mov rdi, rax
mov dword ptr [rdi], 1
mov esi, offset typeinfo for int
xor eax, eax
mov edx, eax
call __cxa_throw
jmp .LBB0_5
mov rcx, rax
mov eax, edx
mov qword ptr [rbp - 16], rcx
mov dword ptr [rbp - 20], eax
lea rdi, [rbp - 8]
call Bar::~Bar() [base object destructor]
jmp .LBB0_4
After the initialization of bar, if b is false, the code will just jump to .LBB0_3which calls Bar's destructor, unwinds the stack pointer rsp and returns.
.LBB0_3:
lea rdi, [rbp - 8] # store `this` in rdi (dictated by AMD64 ABI)
call Bar::~Bar() [base object destructor] # call the dtor
add rsp, 32 # unwind the stack
pop rbp # restore caller's frame pointer
ret # return
Now let's take a look at main.
main: # @main
push rbp
mov rbp, rsp
sub rsp, 32
mov dword ptr [rbp - 4], 0 # looks useless
xor edi, edi # set edi to zero (again dictated by AMD64 ABI)
call func(bool)
jmp .LBB2_1
.LBB2_1:
lea rdi, [rbp - 8] # store `this` foo's addr in rdi
call Foo::~Foo() [base object destructor]
jmp .LBB2_4
...
.LBB2_4:
xor eax, eax # set eax (return value) to zero
add rsp, 32 # unwind the stack
pop rbp # restore caller's frame pointer
ret
The reason why it uses xor eax eax to set a register to 0 is for efficiency reason. It produces shorter opcode and enables the processor to perform register renaming. Notice the mov dword ptr [rbp - 4], 0 line in main. It initializes the next four bytes on the stack to zero, which we are not really using anyway. If you switch from clang to gcc, this line would disappear (with the same flags).
If you follow the labels from main, to .LBB2_1, to .LBB2_4, all they are doing is just calling func, destructing foo, and returning 0. The code runs as if the exception handling logic is not even there to begin with, when it's not thrown. This is known as zero-cost exception handling. It's an implementation detail for programming languages. E.g. C++ and Java have zero-cost exception handling. CPython 3.11 is thinking about adding zero-cost exception handling support.
You might be thinking, we are not even handling an exception in this code, of course it's zero-cost. How can we call it exception handling to begin with? Well, we actually did handle the exception, it just didn't throw. We can rewrite the code as,
int foo(bool b) {
if (b) {return -1;} // exceptional case
else {return 0;}
}
int main() {
int ret = foo(false);
if (ret != 0) { // error handling }
}
Notice that even if func never returns -1 here, main needs to check the return value (handling the exception). A smart compiler can optimize this away in this case. But in practice, func will error out sometimes. So main always needs to check the return value of func because it's possible that it needs to handle the error case. This check, a form of exception handling, is not free, even though 99% of the time there are no errors. This is essentially how Python implements its exception handling. It checks if there's an exception PyErr all the time, and invokes the handling logic if needed. CPython's exception handling (before 3.11) is not zero-cost. With C++ exception, on the other hand, it's free (zero-cost), when there are no exceptions (if you discount iTLB misses). There are binary layout optimizers such as BOLT that can even further optimize the physical layout of the code to minimize iTLB misses.
This strategy is the equivalent of optimistic concurrency control in database. As you might have guessed, it comes with a cost. When an optimistic prediction is wrong — when an exception is actually thrown — it's much more expensive.