With this post, I want to bring your attention to source code improvements in MySQL 8.0. MySQL 8.0 modernizes the code base by using C++11 constructs, being warning-free on more compilers and platforms, being UBSan- and ASan- clean, improving header file dependencies, improving the coding style, and better developer documentation.
C++11
With MySQL 8.0, we have started to modernize our C++ usage by using C++11 constructs. Here are some examples of C++11 constructs in use by 8.0:
- std::atomic — fixed lots of bugs for us over the old use of volatile, replaced home-grown compiler-specific atomic
- thread_local — gave us nice speedups over our old code
- Initializers in structs/classes — simplified construction/destruction
- std::snprintf — replaced the old my_snprintf
- std::unordered_map/std::unordered_set — much faster than the old HASH
- std::call_once — replaced our home-grown my_thread_once
- std::unique_ptr — makes cleanup significantly safer (RAII pattern)
- constexpr functions — enabled some speedups in InnoDB
MySQL 8.0 moving to C++11 requires GCC version >= 4.8 (Linux), Clang >= 3.4 (macOS, FreeBSD), Visual Studio >= 2015 (Windows) or Oracle Studio 12.5 (Solaris). For comparison, MySQL 5.7 compiled fine with GCC >= 4.4, Clang >= 3.3, VS 2013 or Oracle Studio 12.2.
Similarly, the client library now assumes a C99 or C++11 compiler, in order to be able to access now-standard language features such as the bool type. The set of shipped client headers has also been slimmed down significantly; you no longer need the complete set of server headers to build against the client library, just a much smaller, platform-independent set.
Header File Dependencies
We have started cleaning up header files dependencies, i.e. work on “include what you use” and on reorganizing header files to remove build dependencies. We have fixed ambiguous include paths; almost all should now be from the root. Incrementality has increased a lot after e.g. my_global.h went away, and sql_class.h was also reduced a fair bit in weight. Shipped client headers are self-contained and much more sane. For example, client headers are now platform independent (no difference between 32- and 64-bit Linux).
Warning-Free
With MySQL 8.0, we have invested in getting warning-free compiles on a wider range of compilers and platforms. MySQL 8.0 is warning-free on GCC up to and including 8, and warning free on Clang on Mac for the first time. MySQL 8.0 is warning-free with GCC 8 and Clang 6 with these options:
- C: -Wall -Wextra -Wformat-security -Wvla -Wundef -Wmissing-format-attribute -Wwrite-strings -Werror
- CC+: -Wall -Wextra -Wformat-security -Wvla -Wundef -Wmissing-format-attribute -Woverloaded-virtual -Wno-missing-field-initializers -Wimplicit-fallthrough=2 -Wlogical-op -Werror
Code Sanitizers
With MySQL 8.0, we have had a strong focus on AddressSanitizer (Asan) and UndefinedBehaviorSanitizer (UBsan). We strongly believe in using tools like Asan and UBsan to increase code quality. We are now Asan-clean with options -fsanitize=address -fsanitize-address-use-after-scope under GCC 8 and Clang 6. We are also UBsan-clean with option -fsanitize=undefined under GCC 8 and Clang 6. We’ve fixed a number of bugs detected by UBsan and Asan.
Coding Standard
With MySQL 8.0 we have abandoned the historical MySQL Server and InnoDB coding styles and moved on to the Google C++ Style Guide. The code base has been reformatted as of MySQL 8.0.11. The motivation for this change was to achieve one common coding style (earlier the Server and InnoDB layers had different coding styles), as well as getting tooling support to enforce the coding style (clang-format --style=google). For the time being, it is mostly the formatting that has changed, but we have also started the process of conforming to other aspects of the Google C++ Style Guide.
Benefits of a common coding standard include:
- Easier to get started for new developers (only one style, and a
style that’s used by others, so it’s not MySQL specific). - In some cases, makes the code easier to read (some parts were hard to
read earlier). - Better tool support for auto-formatting, which again leads to easier
detection of bugs hiding in incorrect indentation. - One style all over => easier to write code and focus on what matters.
Developer Documentation
With MySQL 8.0 we are moving away from the historical MySQL Internals Manual and on to the MySQL Source Code Documentation. As the name indicates, the MySQL source code documentation resides in the source code and is managed in the same way as any other source code. We have finished the work in some areas, such as documenting the MySQL Test Framework, and for other areas we will add developer documentation over time. The developer documentation is written in Doxygen.
