PgSQL即时编译JIT | 第1期 | JIT初识

PgSQL即时编译JIT | 第1期 | JIT初识

JIT是Just-In-Time的缩写，也就是说程序在执行的时候生成可以执行的代码，然后执行它。在介绍JIT之前，需要说下两种执行方式：解释执行和编译执行。其中解释执行是通过解释器，将代码逐条翻译成机器码；而编译执行是提前翻译成机器码。编译执行又分为动态编译和静态编译，其中动态编译指在运行时进行编译，与之相对的就是静态编译。JIT编译就是动态编译的一种技术。优点：编译代码的速度快了，运行时根据运行态编译代码，少很多条件判断和无关代码，效率会很高；缺点：运行时需要进行编译产生机器码，带来额外开销。因此，需要针对不同情况进行测试和分析，评估带来的收益是否大于带来的开销。

1、LLVM

PgSQL通过LLVM（Low Level Virtual Machine底层虚拟机）进行代码生成。LLVM是一款开源编译器框架，我们主要关注LLVM IR的格式以及生成LLVM IR的API。IR全称是Intermediate Representation，即“中间表示”。Clang将PgSQL代码编译成中间表示.bc文件，然后通过LLVM根据运行时状态，将.bc动态编译生成最终执行的代码。

2、PgSQL编译与LLVM

PgSQL的执行器基于火山模型，执行计划树的每个节点定义为Plan，执行时遍历从树根开始执行计划树从而驱动执行器的执行。问题：计算过程中，无法明确操作的类型，需要频繁对类型进行识别，导致计算过程中产生了大量的动态类型识别需求；并且处理逻辑笨重：递归、封装、类型判断等这样的代码实现方式，带来频繁的函数调用以及缓存使用率低、对指令集不敏感等。PgSQL仅对表达式计算进行了JIT加速。首先从thinlto说起。

lto就是链接时优化，在编译阶段，Clang将PgSQL的.c文件编译成中间表示.bc文件，执行时通过LLVM将.bc文件进行链接优化和内联优化，最终根据执行状态生成执行需要的机器码。

传统的LLVM LTO，也就是通过clang -cc1 -flto生成原生字节码.o文件。在frontend层并行生成LLVM字节码文件，这个过程中有一些初始优化；linker层通过LLVM作为一个linker查进将所有字节码文件链接生成一个module的.bc文件；进行代码生成时，将.bc文件加载内存后通过优化和内联进行代码生成。Single-threaded very boring usual optimizations Potentially threaded CodeGen。在实践中，LTO通常需要大量内存（一次性保存所有IR）并且非常慢。若通过-g启用了调试信息，IR的大小和需要的内存还会显著增加。当任何输入源发生变化时，从LTO步骤开始的所有内容都必须重新执行，使得增量构建变得不太有效。

ThinLTO：第一阶段frontend全并行处理+初始优化，生成.bc字节码文件，同时会为每个函数可生成summary信息。第二阶段：不需要解析IR中间表示代码，只需要将summary信息链接：thin-link。基于summary信息完全并行跨模块进行函数导入，导入的函数在内联后会被删除。第三阶段：进行优化后生成机器码，Fully-parallel (very boring) usual optimizations and CodeGen。它的串行步骤非常轻量且快速，不需要加载字节码合并单个庞大模块来执行这些分析，而是在串行链接步骤中利用每个模块的摘要进行全局分析。ThinLTO全局分析所启用的关键转换是函数导入，只有可能进行内联的函数才被导入到每个模块中。最大程度减少了每个ThinLTO后端的内存开销，同时最大化了最有影响力的跨模块优化机会。

总之，ThinLTO的核心是将程序分为多个模块，每个模块可以独立进行编译和优化。然后通过使用一个索引文件（summary，也就是.bc的索引文件）来跟踪每个模块的信息，以便在链接阶段进行全局优化。这种方式可以减少编译时间和内存消耗，同时仍能够实现类似于WPO（例如GCC的-fwhole-program开关）的优化效果。

PgSQL中configure时指定--with-llvm，然后生成的Makefile.global.in会带有对JIT的相关设置，使用thinlto技术生成带有模块摘要的IR：

install_llvm_module通过llvm-lto -thinlto -thinlto-action=thinlink对每个代码目录的文件夹生成摘要文件，比如生成字节码后在lib/postgres/bitcode目录下postgres对应postgres.index.bc。

Index.bc是bc文件的索引，bc文件的生成是通过clang编译C文件得到，bc文件级别编译时，还会有个优化，也就是编译过程中-O0、-O1、-O2的优化。在configure中指定：

使用不同的编译参数会得到差异很大的bc文件，-O0时所有函数的noInline属性都是1，O2时才会有nonInline=0的函数，也就是代码生成时才能进行inline优化。

参考

https://llvm.org/devmtg/2016-11/Slides/Amini-Johnson-ThinLTO.pdf