[llvm-dev] Status of Garbage Collection with Statepoints in LLVM

[David Chisnall via llvm-dev]

On 4 Mar 2016, at 01:02, Sanjoy Das via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> PlaceSafepoints is inadequate only if you have asynchronous
> invalidation -- i.e. thread X is spinning in a long running loop while
> thread Y loaded a class that makes the code running in thread X
> invalid, so thread X needs to be polling for deopt safepoints.  If all
> your invalidation events are synchronous then deopt bundles +
> PlaceSafepoints should be enough for both deoptimization and precise
> relocating GC.

Presumably this also depends on the memory model that your language provides.  If it’s something like Go, where no happens-before relationships are established between threads by any mechanism other than explicit synchronisation (atomics or message passing), then it’s perfectly fine for a thread in a long-running loop that doesn’t contain any safepoints to see a stale copy for a very long time.

David