配置openjdk调试环境
先决条件
首先在Ubuntu 18.04上编译SlowDebug版本的openjdk。注意，这里我选择的是x86处理器的电脑。苹果M系列属于ARM芯片，指令集不一样。由于我在苹果上进行垃圾回收调试的时候会报SIGILL错误。为了了解JVM的内部工作原理，不要在这种问题上过多纠结，另外，x86的资源也更丰富一些，因此，我直接选择x86处理器进行调试。
我机器的处理器为AMD Ryzen 7 8845HS w/ Radeon 780M Graphics 3.80 GHz
为了减少寻找在何处调试的时间，这里告诉大家，直接定位到
openjdk/build/linux-x86_64-normal-server-slowdebug/jdk/bin
这里面就是JVM虚拟机可执行文件的入口。例如，平时大家执行的
java -version
就是调用这里的java可执行文件。如果你进入该文件夹，并执行当前文件夹下的
./java -version
能够正确显示版本号，则证明编译成功了。
工具选择
如果使用gcc和g++编译的openjdk，那么就选择gdb进行调试。前面已经说了，目标jdk是openjdk11，操作系统为Ubuntu 18.04，这里直接用apt install安装gdb即可进行调试。
为什么选用gdb而不是图形界面调试
为此问题我花了1个月，一直尝试看能否用IDE的调试工具进行调试，然而结果不尽人意。我想基于gdb调试主要有2个原因。
- JVM自身的开发调试环境
JVM的初衷是在Linux下运行的虚拟机，甚至想独立于操作系统，但是目前看起来没有办法完全脱离操作系统运行，而且其内部实现也调用了系统库。如果是在Linux下运行，那么用命令行进行调试就能解决几乎全部的问题。
- 图形界面调试也是基于命令行
图形界面调试工具，例如，visual studio code，实际上是通过配置文件选择使用何种调试器，只不过将调试器原本应该通过终端显示的内容转换到IDE中显示。但这里实际上是绕了一个弯子，有些调试还不能很好的支持，比如对汇编语言的调试，而这正是JVM中需要考虑的部分。
- 命令调试可100%定位函数
目前JVM源码中main函数有多处，我如何知道哪里是启动main函数？
以往，对于C#或者Java程序，我们都是通过打开已知的文件，比如在C#中的program.cs文件，找到main函数，以确定函数入口，但是对于JVM这种C++编写的大型软件，看起来只能用命令行的gdb来确定入口main函数了。比如：
/* main.c */
#include <stdio.h>int main(){printf("Hello world!");return 0;
}
通过gcc编译
gcc -g main.c -o main
使用gdb调试上述C程序时，只需要指定要在哪个函数断开，不需要特别指定文件。
gdb ./main
b main
r
如果调试JVM，同样也只需要执行b main就会自动寻找在哪个main函数上停止。
如果直接在生成的文件夹下执行gdb ./java会报错
在openjdk/build/linux-x86_64-normal-server-slowdebug/jdk/bin下执行
gdb -command=.gdbinit ./java
然后设置断点
b main
然后运行
r
此时，JVM就停止在了main函数处。至少，我们已经能够进入JVM了。
如果在visual studio code中，你还可以将鼠标放在终端的文件名上，然后按住ctrl+鼠标右键即可直接导航到文件处。 MacOS是command+鼠标右键进行导航
