我们将YJIT Ruby编译器移植到Rust的经验

Last year, my team at Shopify implemented YJIT, a new Just-In-Time (JIT) compiler for CRuby, which was recently upstreamed as part of Ruby 3.1. Because the CRuby codebase is implemented in C99, we also decided to implement YJIT in C99 so that integration with the rest of the CRuby codebase would be as simple as possible. However, we found that implementing a JIT compiler in plain C quickly became tedious, and as we kept adding features to YJIT, we found that the complexity of our project became hard to manage.

去年，我在Shopify的团队实施了YJIT，一个用于CRuby的新的即时编译器（JIT），它最近作为Ruby 3.1的一部分被上游化。因为CRuby代码库是用C99实现的，所以我们也决定用C99实现YJIT，这样与CRuby代码库的其他部分的集成就会尽可能的简单。然而，我们发现用纯C语言实现JIT编译器很快就变得乏味了，而且随着我们不断为YJIT增加功能，我们发现我们项目的复杂性变得难以管理。

Many people would tell you that the biggest burden when programming in C is worrying about buffer overflows and accidentally dereferencing null pointers. However, I think that what can make programming in C tedious on a day-to-day basis is that the C language doesn’t provide many tools to manage complexity. There are no modules or namespaces, so you have to prefix identifiers to avoid name collisions. You have to worry about the order of your declarations and adding prototypes in the right places. A lot of information is duplicated in various header files. Constants and macros use the C preprocessor, which can lead to strange bugs. There are no classes or interface types to cleanly encapsulate functionality, and there are no standard container types. We implemented our own dynamic array type, which we had to manipulate through awkward preprocessor macros with no type checking.

许多人会告诉你，用C语言编程时最大的负担是担心缓冲区溢出和意外地取消引用空指针。然而，我认为使C语言编程在日常工作中变得乏味的原因是，C语言没有提供很多工具来管理复杂性。没有模块或命名空间，所以你必须给标识符加前缀以避免名称冲突。你必须担心你的声明的顺序和在正确的地方添加原型。很多信息在各种头文件中都是重复的。常量和宏使用C语言的预处理器，这可能导致奇怪的错误。没有类或接口类型来干净地封装功能，也没有标准的容器类型。我们实现了自己的动态数组类型，我们不得不通过笨拙的预处理器宏来操作，没有类型检查。

Compilers are some of the most complex pieces of software in existence, and I think there’s a fair argument that JIT compilers are even more complex (or at least harder to debug) than ahead...