3 ms·

Garbage collection is godsend when it comes to concurrency algorithms. Determine liveness is hard on its own, ABA issues are totally eliminated by GC enabled s

by xxs 8y ago

Garbage collection is godsend when it comes to concurrency algorithms. Determine liveness is hard on its own, ABA issues are totally eliminated by GC enabled setups. As for energy costs, I'd bet generation/copy collectors are cheaper than malloc/free. They are way cheaper than ref. counting which requires deeper pipelines + branch predictor extra load; ref. counting with concurrency requires atomics, cache coherency traffic, flushing of the write queue and memory barriers.

gpderetta 8y ago
> Determine liveness is hard on its own, ABA issues are totally eliminated by GC enabled setups. FWIW, Herlihy has examples of ABA issues on algorithms implemented in Java.
- xxs 8y ago
  I wonder what that be... It can happen with primitives only and the usual solution is: increment only and use prepare/publish with two distinct counters (for circular buffers alike). Do you have any references?
  - gpderetta 8y ago
    Herlihy, The Art of Multiprocessor Programming. I would quote chapter and verse, but somehow the book has disappared from my desk.
    - xxs 8y ago
      I tried to have a quick look: 10.6 Memory Reclamation and the ABA Problem "There are several reasons we might want to do this. Languages such as C or C++ do not provide garbage collection. Even if garbage collection is available, it is often more efficient for a class to do its own memory management, particularly if it creates and releases many small objects. Finally, if the garbage collection process is not lock-free, we might want to supply our own lock-free memory reclamation." There is =absolutely= no reason to attempt and recycle nodes (for queue/stacks) in Java, esp. 'small object'. It'd perform worse than pretty much any GC. The solution to use "AtomicStampedReference" is a weak one as - it does not enjoy JVM intrinsics. It's an example of course [and AtomicStampedReference has it uses], but the better option is just keep creating new objects and let them trivially die in the young gen. Again ABA does not exist in Java unless attempting to reuse objects (pooling direct memory would be the closest case; Direct memory [direct ByteBuffer] is one of the areas where GC sucks hard) Personally I have not read the book, so I cannot comment on its contents. I have quite extensive experience coding lock free data structures.
MaxBarraclough 8y ago
> ABA issues are totally eliminated by GC enabled setups Doesn't the same approach work with a thread-safe reference-counting approach to memory-management? The big difference between tracing GC, and reference-counting, is the ability to handle reference-cycles. Is that relevant here?

by xxs 8y ago

gpderetta 8y ago

> Determine liveness is hard on its own, ABA issues are totally eliminated by GC enabled setups. FWIW, Herlihy has examples of ABA issues on algorithms implemented in Java.

xxs 8y ago
I wonder what that be... It can happen with primitives only and the usual solution is: increment only and use prepare/publish with two distinct counters (for circular buffers alike). Do you have any references?
- gpderetta 8y ago
  Herlihy, The Art of Multiprocessor Programming. I would quote chapter and verse, but somehow the book has disappared from my desk.
  - xxs 8y ago
    I tried to have a quick look: 10.6 Memory Reclamation and the ABA Problem "There are several reasons we might want to do this. Languages such as C or C++ do not provide garbage collection. Even if garbage collection is available, it is often more efficient for a class to do its own memory management, particularly if it creates and releases many small objects. Finally, if the garbage collection process is not lock-free, we might want to supply our own lock-free memory reclamation." There is =absolutely= no reason to attempt and recycle nodes (for queue/stacks) in Java, esp. 'small object'. It'd perform worse than pretty much any GC. The solution to use "AtomicStampedReference" is a weak one as - it does not enjoy JVM intrinsics. It's an example of course [and AtomicStampedReference has it uses], but the better option is just keep creating new objects and let them trivially die in the young gen. Again ABA does not exist in Java unless attempting to reuse objects (pooling direct memory would be the closest case; Direct memory [direct ByteBuffer] is one of the areas where GC sucks hard) Personally I have not read the book, so I cannot comment on its contents. I have quite extensive experience coding lock free data structures.

MaxBarraclough 8y ago

> ABA issues are totally eliminated by GC enabled setups Doesn't the same approach work with a thread-safe reference-counting approach to memory-management? The big difference between tracing GC, and reference-counting, is the ability to handle reference-cycles. Is that relevant here?