Slight correction, write barriers are usually more expensive(even far more complex sometimes).
HOWEVER reads outnumbers writes by a large margin of 10:1 in common code (iirc this was measured in Java code some 20 years ago so might vary by language), so most GC implementations only use write-barriers since they're an prerequisite for incremental GC marking.
Read-barriers are a prerequisite for incremental GC moving if you need to compact the heap (many earlier GC's accept pauses for compacting work since they often compact smaller parts of the heap in each pause), Java ZGC introduced incremental compacting in recent years and whilst it hurts computation performance(called "mutator" in papers) more than just write barriers they were positively surprised at how low they managed to get the penalty.
Comments
'write barrier' is a standard term (along with 'read barrier'). See memory management glossary: https://www.memorymanagement.org/glossary/b.html#barrier-1
https://twitter.com/stevemblackburn/status/14942409060061102...
Read barriers are more expensive.
Slight correction, write barriers are usually more expensive(even far more complex sometimes).
HOWEVER reads outnumbers writes by a large margin of 10:1 in common code (iirc this was measured in Java code some 20 years ago so might vary by language), so most GC implementations only use write-barriers since they're an prerequisite for incremental GC marking.
Read-barriers are a prerequisite for incremental GC moving if you need to compact the heap (many earlier GC's accept pauses for compacting work since they often compact smaller parts of the heap in each pause), Java ZGC introduced incremental compacting in recent years and whilst it hurts computation performance(called "mutator" in papers) more than just write barriers they were positively surprised at how low they managed to get the penalty.