编译期不负责也不感知SafePoint对齐；异常表由javac静态生成，仅用于运行时异常跳转定位；SafePoint由JIT在生成本地代码时按需插入于catch/finally入口等位置，确保执行安全。
编译期不会主动“对齐”异常处理表跳转地址与垃圾回收安全点（SafePoint），二者在 JVM 中属于不同层级、不同目的的机制，设计上本就不需要也不支持直接对齐。
异常表（Exception Table）是字节码层面的静态结构
它由 javac 在编译时生成，嵌入在方法的 Code 属性中，仅记录 [from, to, target, type] 四元组，用于运行时快速定位 catch/finally 入口。JVM 查找异常处理器时，只关心当前 PC 是否落在 from ≤ pc < to 范围内，并匹配异常类型——这个过程完全不涉及 SafePoint。
SafePoint 是运行时 JIT 编译器插入的协作式暂停点
它只存在于被 JIT 编译后的本地代码（native code）中，由 C1/C2 编译器在生成机器指令时，选择性地插入在：
- 方法返回前
- 循环回边（loop back-edge）
- 调用指令前后（尤其是可能触发 GC 的调用）
- 显式检查点（如
Thread.isInterrupted()等）
这些位置必须满足两个条件：
- 当前线程能在此处安全暂停（寄存器和栈状态一致、对象引用清晰）
- 不影响程序语义（不能插在赋值中途或锁持有中间）
关键事实：
- 解释执行（Interpreter）下，每条字节码指令执行完都会隐式检查 SafePoint，因此
target指向的 catch 块起始位置天然可作为 SafePoint； - JIT 编译后，
target对应的机器码入口处，编译器会按需插入 SafePoint 检查（例如在进入 catch 块的第一条有效指令前）； - finally 块因被冗余生成多份（JDK 1.4.2+），其入口同样会被 JIT 视为常规代码路径，按需设 SafePoint；
-
没有编译期规则强制要求
handler_pc必须等于某个 SafePoint 地址——JVM 保证的是：只要线程到达该地址并开始执行，就已处于可安全 GC 的状态。
所以准确回答是：
- 编译期不负责对齐，也不感知 SafePoint；
- 对齐是运行时 JIT 编译器的职责，它会在生成本地代码时，确保所有异常跳转目标（包括 catch、finally 入口）所在位置具备 SafePoint 语义；
- 解释器模式下无需显式对齐，因为 SafePoint 检查粒度更细（逐字节码）。
