tlab指针归位必须在safepoint进行，因为只有此时线程状态确定、oopmap可准确映射寄存器与栈中top指针位置，vm才能安全重置tlab分配状态，避免寄存器污染、栈帧撕裂和并发冲突。
TLAB（Thread Local Allocation Buffer）指针的归位与置空，并非由 GC 直接“强行”操作，而是依赖 Safepoint 提供的线程状态一致性窗口，让 JVM 能在所有线程同步暂停时，安全地重置每个线程的本地分配状态。这个过程不涉及暴力修改寄存器或破坏栈帧，核心在于“时机可控”和“状态可读”。
TLAB 指针为何必须在 Safepoint 归位
每个线程的 TLAB 是一块私有堆内存区域，其分配指针（如 top 和 end）保存在线程本地变量或寄存器中，运行时持续变化。GC 无法在任意时刻读取这些值——因为它们可能正被写入中途、尚未对齐，或已被编译器优化掉。只有在 Safepoint，JIT 编译器生成的 OopMap 才能准确指出：该线程当前栈帧和寄存器中，哪些位置存着 TLAB 的 top 指针、哪些是有效边界。此时，VM 才能可靠地将这些指针“归位”到 TLAB 当前已分配的末尾（即实际使用上限），并把未用完的剩余空间标记为可回收。
Safepoint 如何支撑 TLAB 置空逻辑
TLAB “置空”本质不是清零内存，而是让线程放弃当前 TLAB，下次分配时重新申请新块。这需要两个前提：
- 线程必须停在已知状态，确保它不会在释放途中继续用旧 TLAB 分配对象；
- VM 必须能定位并冻结该线程持有的 TLAB 元数据（如 start、top、end、pf_top）；
- 全局需确认所有线程都完成归位，才能统一更新堆的 TLAB 统计、触发 Refill 或调整大小策略。
这些操作全部发生在 Safepoint 同步完成后、GC 标记开始前的短暂窗口内。没有 Safepoint，TLAB 状态就是“流动的”，置空动作会与分配竞争，导致内存泄漏或分配越界。
关键实现细节：轮询页与 poll 检查点的作用
HotSpot 并不靠线程主动“上报”位置，而是通过 polling 机制驱动归位：
- 每个 JIT 编译的方法在返回前、每个非 counted 循环回跳前，插入一条 poll 指令，读取一个特殊内存地址（即轮询页中的 _poll_page_disarmed_value）；
- 当 GC 触发，VM 调用 arm_safepoint()，将该地址切换为不可访问的坏页地址（_poll_page_armed_value）；
- 线程下次执行 poll 指令时触发 SIGSEGV，陷入内核后由 VM 处理，转入 safepoint handler，此时才真正保存寄存器、解析 OopMap、归位 TLAB 指针；
- 解释器字节码边界也内置 poll，保证即使未 JIT 的代码也能及时响应。
也就是说，TLAB 指针的归位不是“立即生效”的指令，而是线程运行到下一个合法检查点后，由 VM 在上下文切换中完成的一次状态快照与修正。
为什么不能绕过 Safepoint 强制操作
绕过 Safepoint 尝试直接修改 TLAB 指针会导致三类问题：
- 寄存器污染：JIT 可能将 top 指针存在某个通用寄存器（如 r12），且未在 OopMap 中登记，VM 无法定位；
- 栈帧撕裂：方法正在执行 new 指令中间，top 已更新但对象构造未完成，此时归位会丢失半截对象；
- 并发冲突：线程 A 在修改 top，线程 B 同时从同一 TLAB 分配，造成指针错乱或覆盖。
只有 Safepoint 能提供“所有引用落位、栈帧完整、寄存器映射明确”的确定性现场，这是 TLAB 安全管理不可替代的基础。
