It is conceptually very simple: the GC stops the mutator threads while compaction is in progress and objects are moved around; throughput-focused GCs generally do that, better ones do it in parallel with multiple GC threads.

This has an obvious impact on performance that needs to be compared with the mutator calling malloc/free in a non-GC system. The function isn't called "free" because it runs in zero time, you know.

> What happens when the pointers are in registers? What happens when the loop is occurring in a thread running on another core?

These are all ancient-solved problems. When any interruption occurs, CPU state is spilled onto the stack. Depending on the architecture, the current register usage is either part of the language ABI or determined by the code location indicated by the PC.

> Yes, you can make GC work in these situations, but you are going to pay for it. In perf.

I'm not a big fan of Java the language, but the JVM gets incredible performance doing stuff exactly like this. That and optimization features like inlining virtual function calls (a distinctly faster-than-C++ feature) should be a huge inspiration and impetus towards higher level machine optimization, rather than the human hand-holding the machine through its execution details.