4 ms·
You can have completely concurrent GC, without pausing threads. https://github.com/pebal/sgcl https://github.com/pebal/sgcl
by pebal 3y ago
You can have completely concurrent GC, without pausing threads.
https://github.com/pebal/sgcl https://github.com/pebal/sgcl
- jandrewrogers 3y agoHow 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.
- pebal 3y agoYou either pause the worker threads or share the state, there's no other way. However, the GC thread does not modify the data state.
- _se 3y agoSo, 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.
- pebal 3y agoI 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.
- deleted 3y ago[deleted]