Making C++ Exception Handling Smaller On x64

Modi Mo

Modi

Visual Studio 2019 Preview 3 introduces a new feature to reduce the binary size of C++ exception handling (try/catch and automatic destructors) on x64. Dubbed FH4 (for __CxxFrameHandler4, see below), I developed new formatting and processing for data used for C++ exception handling that is ~60% smaller than the existing implementation resulting in overall binary reduction of up to 20% for programs with heavy usage of C++ exception handling.

How Do I Turn This On?

FH4 is currently off by default because the runtime changes required for Store applications could not make it into the current release. To turn FH4 on for non-Store applications, pass the undocumented flag “/d2FH4” to the MSVC compiler in Visual Studio 2019 Preview 3 and beyond.

We plan on enabling FH4 by default once the Store runtime has been updated. We’re hoping to do this in Visual Studio 2019 Update 1 and will update this post once we know more.

Tools Changes

Any installation of Visual Studio 2019 Preview 3 and beyond will have the changes in the compiler and C++ runtime to support FH4. The compiler changes exist internally under the aforementioned “/d2FH4” flag. The C++ runtime sports a new DLL called vcruntime140_1.dll that is automatically installed by VCRedist. This is required to expose the new exception handler __CxxFrameHandler4 that replaces the older __CxxFrameHandler3 routine. Static linking and app-local deployment of the new C++ runtime are both supported as well.

Now onto the fun stuff! The rest of this post will cover the internal results from trialing FH4 on Windows, Office, and SQL, followed by more in-depth technical details behind this new technology.

Motivation and Results

About a year ago, our partners on the C++/WinRT project came to the Microsoft C++ team with a challenge: how much could we reduce the binary size of C++ exception handling for programs that heavily used it?

In context of a program using C++/WinRT, they pointed us to a Windows component Microsoft.UI.Xaml.dll which was known to have a large binary footprint due to C++ exception handling. I confirmed that this was indeed the case and generated the breakdown of binary size with the existing __CxxFrameHandler3, shown below. The percentages in the right side of the chart are percent of total binary size occupied by specific metadata tables and outlined code.

Size Breakdown of Microsoft.UI.Xaml.dll using __CxxFrameHandler3

I won’t discuss in this post what the specific structures on the right side of the chart do (see James McNellis’s talk on how stack unwinding works on Windows for more details). Looking at the total metadata and code however, a whopping 26.4% of the binary size was used by C++ exception handling. This is an enormous amount of space and was hampering adoption of C++/WinRT.

We’ve made changes in the past to reduce the size of C++ exception handling in the compiler without changing the runtime. This includes dropping metadata for regions of code that cannot throw and folding logically identical states. However, we were reaching the end of what we could do in just the compiler and wouldn’t be able to make a significant dent in something this large. Analysis showed that there were significant wins to be had but required fundamental changes in the data, code, and runtime. So we went ahead and did them.

With the new __CxxFrameHandler4 and its accompanying metadata, the size breakdown for Microsoft.UI.XAML.dll is now the following:

Size Breakdown of Microsoft.UI.Xaml.dll using __CxxFrameHandler4

The binary size used by C++ exception handling drops by 64% leading to an overall binary size decrease of 18.6% on this binary. Every type of structure shrank in size by staggering degrees:

EH Data__CxxFrameHandler3 Size (Bytes)__CxxFrameHandler4 Size (Bytes)% Size Reduction
Pdata Entries147,864118,26020.0%
Unwind Codes224,28492,81058.6%
Function Infos255,44027,75589.1%
IP2State Maps186,94445,09875.9%
Unwind Maps80,95269,75713.8%
Catch Handler Maps52,0606,14788.2%
Try Maps51,9605,19690.0%
Dtor Funclets54,57045,73916.2%
Catch Funclets102,4004,30195.8%
Total1,156,474415,06364.1%

 

Combined, switching to __CxxFrameHandler4 dropped the overall size of Microsoft.UI.Xaml.dll from 4.4 MB down to 3.6 MB.

Trialing FH4 on a representative set of Office binaries shows a ~10% size reduction in DLLs that use exceptions heavily. Even in Word and Excel, which are designed to minimize exception usage, there’s still a meaningful reduction in binary size.

BinaryOld Size (MB)New Size (MB)% Size ReductionDescription
chart.dll17.2715.1012.6%Support for interacting with charts and graphs
Csi.dll9.788.6611.4%Support for working with files that are stored in the cloud
Mso20Win32Client.dll6.075.4111.0%Common code that’s shared between all Office apps
Mso30Win32Client.dll8.117.309.9%Common code that’s shared between all Office apps
oart.dll18.2116.2011.0%Graphics features that are shared between Office apps
wwlib.dll42.1541.122.5%Microsoft Word’s main binary
excel.exe52.8650.294.9%Microsoft Excel’s main binary

 

Trialing FH4 on core SQL binaries shows a 4-21% reduction in size, primarily from metadata compression described in the next section:

BinaryOld Size (MB)New Size (MB)% Size ReductionDescription
sqllang.dll47.1244.335.9%Top-level services: Language parser, binder, optimizer, and execution engine
sqlmin.dll48.1745.834.8%Low-level services: transactions and storage engine
qds.dll1.421.336.3%Query store functionality
SqlDK.dll3.193.054.4%SQL OS abstractions: memory, threads, scheduling, etc.
autoadmin.dll1.771.647.3%Database tuning advisor logic
xedetours.dll0.450.3621.6%Flight data recorder for queries

 

The Tech

When analyzing what caused the C++ exception handling data to be so large in Microsoft.UI.Xaml.dll I found two primary culprits:

  1. The data structures themselves are large: metadata tables were fixed size with fields of image-relative offsets and integers each four bytes long. A function with a single try/catch and one or two automatic destructors had over 100 bytes of metadata.
  2. The data structures and code generated were not amenable to merging. The metadata tables contained image-relative offsets that prevented COMDAT folding (the process where the linker can fold together identical pieces of data to save space) unless the functions they represented were identical. In addition, catch funclets (outlined code from the program’s catch blocks) could not be folded even if they were code-identical because their metadata is contained in their parents.

To address these issues, FH4 restructures the metadata and code such that:

  1. Previous fixed sized values have been compressed using a variable-length integer encoding that drops >90% of the metadata fields from four bytes down to one. Metadata tables are now also variable length with a header to indicate if certain fields are present to save space on emitting empty fields.
  2. All image-relative offsets that can be function-relative have been made function-relative. This allows COMDAT folding between metadata of different functions with similar characteristics (think template instantiations) and allows these values to be compressed. Catch funclets have been redesigned to no longer have their metadata stored in their parents’ so that any code-identical catch funclets can now be folded to a single copy in the binary.

To illustrate this, let’s look at the original definition for the Function Info metadata table used for __CxxFrameHandler3. This is the starting table for the runtime when processing EH and points to the other metadata tables. This code is available publicly in any VS installation, look for <VS install path>\VC\Tools\MSVC\<version>\include\ehdata.h:

This structure is fixed size containing 10 fields each 4 bytes long. This means every function that needs C++ exception handling by default incurs 40 bytes of metadata.

Now to the new data structure (<VS install path>\VC\Tools\MSVC\<version>\include\ehdata4_export.h):

Notice that:

  1. The magic number has been removed, emitting 0x19930522 every time becomes a problem when a program has thousands of these entries.
  2. EHFlags has been moved into the header while dispESTypeList has been phased out due to dropped support of dynamic exception specifications in C++17. The compiler will default to the older __CxxFrameHandler3 if dynamic exception specifications are used.
  3. The lengths of the other tables are no longer stored in “Function Info 4”. This allows COMDAT folding to fold more of the pointed-to tables even if the “Function Info 4” table itself cannot be folded.
  4. (Not explicitly shown) The dispFrame and bbtFlags fields are now variable-length integers. The high-level representation leaves it as an uint32_t for easy processing.
  5. bbtFlags, dispUnwindMap, dispTryBlockMap, and dispFrame can be omitted depending on the fields set in the header.

Taking all this into account, the average size of the new “Function Info 4” structure is now 13 bytes (1 byte header + three 4 byte image relative offsets to other tables) which can scale down even further if some tables are not needed. The lengths of the tables were moved out, but these values are now compressed and 90% of them in Microsoft.UI.Xaml.dll were found to fit within a single byte. Putting that all together, this means the average size to represent the same functional data in the new handler is 16 bytes compared to the previous 40 bytes—quite a dramatic improvement!

For folding, let’s look at the number of unique tables and funclets with the old and new handler:

EH DataCount in __CxxFrameHandler3Count in __CxxFrameHandler4% Reduction
Pdata Entries12,3229,85520.0%
Function Infos6,3862,74757.0%
IP2State Map Entries6,3632,14866.2%
Unwind Map Entries1,4871,4641.5%
Catch Handler Maps2,60360176.9%
Try Maps2,59864875.1%
Dtor Funclets2,3011,52733.6%
Catch Funclets2,6038496.8%
Total36,66319,07448.0%

 

The number of unique EH data entries drops by 48% from creating additional folding opportunities by removing RVAs and redesigning catch funclets. I specifically want to call out the number of catch funclets italicized in green: it drops from 2,603 down to only 84. This is a consequence of C++/WinRT translating HRESULTs to C++ exceptions which generates plenty of code-identical catch funclets that can now be folded. Certainly a drop of this magnitude is on the high-end of outcomes but nevertheless demonstrates the potential size savings folding can achieve when the data structures are designed with it in mind.

Performance

With the design introducing compression and modifying runtime execution there was a concern of exception handling performance being impacted. The impact, however, is a positive one: exception handling performance improves with __CxxFrameHandler4 as opposed to __CxxFrameHandler3. I tested throughput using a benchmark program that unwinds through 100 stack frames each with a try/catch and 3 automatic objects to destruct. This was run 50,000 times to profile execution time, leading to overall execution times of:

__CxxFrameHandler3__CxxFrameHandler4
Execution Time4.84s4.25s

 

Profiling showed decompression does introduce additional processing time but its cost is outweighed by fewer stores to thread-local storage in the new runtime design.

Future Plans

As mentioned in the title, FH4 is currently only enabled for x64 binaries. However, the techniques described are extensible to ARM32/ARM64 and to a lesser extent x86. We’re currently looking for good examples (like Microsoft.UI.Xaml.dll) to motivate extending this technology to other platforms—if you think you have a good use case let us know!

The process of integrating the runtime changes for Store applications to support FH4 is in flight. Once that’s done, the new handler will be enabled by default so that everyone can get these binary size savings with no additional effort.

Closing Remarks

For anybody who thinks their x64 binaries could do with some trimming down: try out FH4 (via ‘/d2FH4’) today! We’re excited to see what savings this can provide now that this feature is out in the wild. Of course, if you encounter any issues please let us know in the comments below, by e-mail (visualcpp@microsoft.com), or through Developer Community. You can also find us on Twitter (@VisualC).

Thanks to Kenny Kerr for directing us to Microsoft.UI.Xaml.dll, Ravi Pinjala for gathering the numbers on Office, and Robert Roessler for trialing this out on SQL.

 

Modi Mo
Modi Mo

Follow Modi   

Reuven Abliyev
Reuven Abliyev 2019-03-10 12:56:11

Just wonder where is magic 0x19930522  coming from?
Is it date when exception where first implemented in MSVC compiler?

Avatar
Runzhen Huang 2019-03-09 18:47:29

Amazing work! I wonder if you have trie compiling PPT and pptlink_desktop with /D2FH4, and what the file size reduction for ppcore.dll? Thanks.

Avatar
alan birtles 2019-03-07 17:23:36

Is FH4 code compatible with FH3? E.g. if I throw an exception inside a dll built with FH4 will an application built with FH3 be able to catch it?