# Making unwinding through JIT-ed code scalable

DevFeed: [Making unwinding through JIT-ed code scalable](<https://devfeed.tech/articles/making-unwinding-through-jit-ed-code-scalable-25078.md>)

Original publisher: [Read original article](<https://databasearchitects.blogspot.com/2022/06/making-unwinding-through-jit-ed-code.html>)

Author: Thomas Neumann (noreply@blogger.com)

Published: 2022-06-26T08:46:00Z

Content type: tutorial

Language: en

Sources: [Database Architects](<https://devfeed.tech/sources/database-architects.md>)

Topics: [C++](<https://devfeed.tech/topics/c-plus-plus.md>), [Exception](<https://devfeed.tech/topics/exception.md>), [gcc](<https://devfeed.tech/topics/gcc.md>), [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [Jule](<https://devfeed.tech/topics/jule.md>), [systems](<https://devfeed.tech/topics/systems.md>)

Tags: [c-plus-plus](<https://devfeed.tech/tags/c-plus-plus.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [concurrent](<https://devfeed.tech/tags/concurrent.md>), [exception](<https://devfeed.tech/tags/exception.md>), [gcc](<https://devfeed.tech/tags/gcc.md>), [hooks](<https://devfeed.tech/tags/hooks.md>), [jit](<https://devfeed.tech/tags/jit.md>), [lock-free](<https://devfeed.tech/tags/lock-free.md>), [mutex](<https://devfeed.tech/tags/mutex.md>), [series](<https://devfeed.tech/tags/series.md>)

## AI overview

This article explains why C++ exception unwinding remains effectively single-threaded when JIT-ed code is registered. It describes limitations in gcc and glibc mechanisms and introduces a gcc patch using a read-optimized lock-free b-tree to support parallel unwinding without atomic writes.

## Source excerpt

Exceptions are a very handy mechanism to propagate errors in C++ programs, but unfortunately they do not scale very well. In all common C++ implementations the unwinding mechanism takes global lock during unwinding, which has disastrous consequences when the number of threads is high. On a machine with 256 hardware context we see worse-than-single-threaded behavior even for relatively modest failure rates. Fortunately the Florian Weimer fixed one contention point in gcc 12 on systems with glibc 2.35 or newer, which gives us scalable exceptions as long as no JIT-ed code has been registered. Unfortunately our system does register JIT-ed code... Which means exception unwinding in our code base is still single-threaded in practice. But we can fix that by teaching gcc to store the unwinding information in a read-optimized b-tree, which allows for fully parallel unwinding without any atomic writes. There is a gcc patch that does just that, but unfortunately it is quite involved and difficult to review. This article series thus explains all parts of the patch and shows how a read-optimized b-tree can be implemented lock-free. In order to keep the article length somewhat reasonable, the discusses is broken into parts: The problem (this article) Replacing the gcc hooks Optimistic Lock Coupling The b-tree b-tree operations When unwinding exceptions, the compiler has to find the corresponding unwinding information for every call frame on the stack between the throw and the catch. gcc uses two different mechanisms for that: For ahead-of-time compiled code it asks glibc to find the unwinding information using either dl_iterate_phdr (on older systems) or _dl_find_object (on systems with glibc 2.35 or newer). Note that this mapping is not static, as shared libraries could be added or removed at any time, potentially during a concurrent unwind. For that reason dl_iterate_phdr was protected by a global mutex, which clearly does not scale. _dl_find_object avoids that mutex by using a