write barrier


세대별 GC는 GC를 수행하지 않을 때도 애플리케이션에 오버헤드가 발생한다는 단점
root에서 신규 세대를 참조하는 경로만 조사한 뒤 그 중 접근 불가능한 상태인 것을 회수하면
그렇다고 오래된 객체를 포함하여 heap 전체를 검사해 버리면 세대별 GC를 하는 의미가 없다
그래서 애플리케이션에서 참조를 대입하거나 rewrite할 때, 오래된 세대에서 신규 세대를 참조하는 경우 해당 참조를 별도로 기록하는 처리가 추가
이와 같은 참조의 ‘mutate’와 함께 부수적으로 진행해야 하는 처리를 ‘write barrier’라고
![](https://www.notion.so/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2F91b10137-4b01-4e06-8395-497fe3e92e6e%2FUntitled.png?table=block&id=65bf9e6d-3ddb-4cee-bf93-c23e71d43272&cache=v2)

 세대별 GC를 사용하면 write barrier 오버헤드에 비해 얻을 수 있는 이점이 더 클 것으로 기대




> [Go 언어의 GC에 대해 - LINE ENGINEERING](https://engineering.linecorp.com/ko/blog/go-gc/)





