{"id":106296,"date":"2022-02-28T07:00:00","date_gmt":"2022-02-28T15:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=106296"},"modified":"2022-02-27T17:20:20","modified_gmt":"2022-02-28T01:20:20","slug":"20220228-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20220228-00\/?p=106296","title":{"rendered":"Zero-cost exceptions aren’t actually zero cost"},"content":{"rendered":"

There are two common models for exception handling in C++. One is by updating some program state whenever there is a change to the list of things that need to be done when an exception occurs, say, because a new exception handler is in scope or has exited scope, or to add or remove a destructor from the list of things to execute during unwinding. Another model is to use metadata to describe what to do if an exception occurs. There is no explicit management of the state changes at runtime; instead, the exception machinery infers the state by looking at the program counter and consulting the metadata.<\/p>\n

Metadata-based exception handling is often misleadingly called zero-cost exceptions<\/i><\/a>, which makes it sound like exceptions cost nothing. In fact, it’s the complete opposite: Metadata-based exception handling should really be called super-expensive exceptions<\/i>.<\/p>\n

The point of metadata-based exception handling is that there is no code in the mainline (non-exceptional) code path for exception support. The hope is that exceptions are rare, so you end up with a net win:<\/p>\n\n\n\n\n\n
Mode<\/th>\nRuntime-managed<\/th>\nMetadata-based<\/th>\n<\/tr>\n
Mainline code<\/td>\nUpdate state at runtime<\/td>\n <\/td>\n<\/tr>\n
Exception occurs<\/td>\nConsult the state to
\nfind the correct handler<\/td>\n		Take the program counter,
\nfind the metadata that applies to it,
\nconsult the metadata to
\nfind the correct handler<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Notice that using metadata-based so-called “zero-cost” exceptions actually results in a significantly higher<\/i> cost for throwing an exception, because the exception-throwing machinery has to go find the metadata so it can look up which handler to run. This metadata is typically stored in a format optimized for size, not speed<\/a>, so extra work has to happen at exception-throwing time to decode the data in order to find the correct handler.<\/p>\n

The name “zero-cost exceptions” refers to the empty box in the upper right corner. There is no code generated to maintain state just in case an exception occurs.<\/p>\n

But even though the box is empty, that doesn’t mean that things are still the same as if there were no exceptions.<\/p>\n

The presence of exceptions means that the code generation is subject to constraints that don’t show up explicitly in the code generation: Before performing any operation that could potentially throw an exception, the compiler must spill any object state back into memory if the object is observable from an exception handler. (Any object with a destructor is observable, since the exception handler may have to run the destructor.)<\/p>\n

Similarly, potentially-throwing operations limit the compiler’s ability to reorder or eliminate loads from or stores to observable objects because the exception removes the guarantee of mainline execution.<\/p>\n

These costs are not visible to the naked eye. They take the form of lost optimization opportunities.<\/p>\n

Zero-cost exceptions are great (despite the blatant misnomer), but be aware that the cost is not actually zero.<\/p>\n","protected":false},"excerpt":{"rendered":"

Shifting the cost to the exceptional path.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-106296","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"

Shifting the cost to the exceptional path.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/106296","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=106296"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/106296\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=106296"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=106296"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=106296"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}