Explain the internal working of safepoints and why the JVM needs them?

A safepoint is a point during execution where every application thread has reached a state with a known, globally consistent set of live object references - a state the JVM can safely inspect or modify without risking a torn or inconsistent view of the heap and stacks.

The JVM needs this guarantee for several operations beyond just stop-the-world GC phases: deoptimization, which falls a JIT-compiled method back to the interpreter when a speculative optimization's assumption turns out to be wrong, biased lock revocation, taking a consistent thread dump, and on-the-fly class redefinition all require the same kind of globally quiescent moment.

flowchart TD
  A[JVM requests a global safepoint] --> B[Compiled code polls a safepoint flag at method returns, loop back-edges, etc.]
  B --> C{Thread reaches a poll point or is already in a safe native/blocked state}
  C -- Yes --> D[Thread parks, waiting at the safepoint]
  C -- No, still running --> B
  D --> E[All threads reached: safepoint operation runs]
  E --> F[Threads resume normal execution]

Getting every thread to a safepoint isn't instantaneous: the JIT compiler inserts lightweight polling instructions at points like method returns and loop back-edges specifically so a thread checks, cheaply and frequently, whether a global safepoint has been requested, and parks itself if so.

A thread already executing native code, say inside a JNI call, is automatically considered "safe" without needing to poll, since it isn't touching JVM-managed heap references during that time - it only needs to check in once it returns from native code.

A single long-running, tight loop whose back-edge somehow lacks a safepoint poll, historically a rare JIT bug or a pathological case, can badly delay every other thread's ability to reach the global safepoint, which is exactly why safepoint poll placement is treated as a correctness-critical detail inside the JIT compiler itself, not just a performance nicety.