Hacker News Reader

How does this work with standard thread-per-core architectures used in high-performance systems? Sharing state with a GC thread defeats the entire purpose even if you had a dedicated GC thread for each working core to reduce contention, since the entire point is to all but eliminate atomics and cache coherency overhead.

This doesn't address the issue with GCs in high-performance systems, it just turns it into a different kind of problem.

View on HN

You either pause the worker threads or share the state, there's no other way. However, the GC thread does not modify the data state.

So, your pauseless GC pauses or requires some form of resource contention (probably mutex-based) to share the state. It's not possible to have a pauseless GC in thread per core, which immediately rules it out for HPC. These are the types of things that the "GC for everything" crowd admits that they don't understand when making such statements.

I misunderstood you. State is shared by mutator threads using atomic::store(memory_order_release). SGCL never stops threads and does not use locks to share state.

Reply on news.ycombinator.com