[Javascript] GC의 구조 (V8)

Javascript는 모든 것이 런타임에 의해 관리되는 스크립팅 언어다.
그래서 메모리 관리 또한 언어 밖 런타임에서 이루어진다.

여기서는 Javscript, 그 중에서도 대표적인 구현체인 V8에서 GC를 처리하는 방법을 간략히 정리해보겠다.

Javascript의 GC는 전반적으로 Java, C# 등과 같은 범용 언어들에 비해 발전속도가 더디고, 메모리 효율이 낮은 편이다.
애초에 언어의 탄생 목적부터가 수명이 굉장히 길거나 메모리 압력이 심한 환경에서 실행하기 위한 목적이 아니었기 때문에 더 그렇다.

그래서 Node.js 같은 게 서버스택으로 꽤 유행하고는 있지만, 여러모로 비효율적인 부분이 많이 존재한다.

굳이 비교하자면 V8의 GC 방식은 Go와 가장 비슷한 것 같다.

여기서는 Java, Go의 GC와도 비교를 종종 할 것이다.
https://m.blog.naver.com/sssang97/223575258532
https://m.blog.naver.com/sssang97/223576600679

세대 기반(Generational) GC

V8 또한 GC 업계의 전통적인 룰에 따라 세대 기반의 객체 관리 시스템을 구현한다.

세대별 GC는 다음과 같은 경험에서 우러난 가설을 토대로 한다.

1. 대부분의 객체는 금방 죽는다.
2. GC에서 살아남은 횟수가 늘어날수록, 그 객체는 더 오래 살아있을 확률이 커진다.

이러한 경험에 힘입어 V8 GC 또한 신세대와 구세대를 별도의 공간에 저장하며 관리한다.

계속해서 살아남을 확률이 높은 객체만 구세대 영역에 모아두고, 나머지를 신세대에 두고서 집중하는 것이다.
이를 통해 수명이 짧은 객체는 빨리빨리 돌면서 정리하고, 수명이 긴 객체는 느릿느릿 확인하면서 관리비용을 줄인다.

V8의 객체 저장 구조를 그림으로 표현하면 이렇다.

신세대(New Space)가 바로 새로 할당된 객체가 저장되는 영역이다. 일단 뭔가 만들어지면 대부분 저기로 간다.

그리고 신세대에서 마이너 가비지 컬렉션이 2번 발생할 동안 살아남은 객체들은 구세대(Old space)로 이동된다.

대충 전체적으로는 이런 흐름을 갖고 있다.
각각에 사용되는 세부 알고리즘은 곧 다루겠다.

Mark and Sweep 알고리즘

현대 GC의 근간이 된 기법 중 하나다.

1960년에 리습의 창시자 매카시가 만들었다.

Java에서도 몇몇 GC 기법은 마크앤 스윕 기반으로 만들어졌고, Go, C#, V8 등은 지금도 이걸 쓴다

V8에서는 구세대 메모리 GC(Major GC)에 Mark and Sweep을 사용한다.
더 정확히 말하면 변종인 Concurrent Mark and Sweep(CMS)과 Mark and Compact를 사용하는 것이긴 하다. 그건 다음 섹션에서 언급하겠다.

https://m.blog.naver.com/sssang97/221567636644

마크앤스윕은 초기에 나온 방법론인만큼 구조가 매우 단순하다.

루트객체들부터 한바퀴 뺑 돌면서 참조되고 있는지를 체크하고, 참조되지 않은걸 싹 지워버린다는 간단한 방법이다.

구현하기에는 편리하지만 단점이 많아서 Java 같은 경우에는 근래에 이 구조를 거의 버렸다.

매 GC 타임마다 모든 객체를 풀스캔하면서 찍고, 또 풀스캔하면서 지워야 하기 때문에 메모리가 커지면 감당이 잘 안된다.

게다가 메모리 파편화도 심하다. 그냥 일단 지우고 보는게 최종 목적이기 때문에 메모리 조각모음같은걸 고려하지도 않았다.
메모리 파편화가 누적될수록 연속된 큰 공간이 없어져서 빈 공간을 찾기도 힘들고, 추가적인 정리작업이 필요해질 수도 있기 때문이다.

Mark and Compact

Mark and Compact는 Mark and Sweep에서 발생하는 메모리 파편화 문제를 해결하기 위해 스텝을 하나 추가한 방법론이다.

Edward Lueders라는 사람이 1974년에 고안했다.

전반적인 동작방식은 마크앤스윕과 거의 비슷하다.

차이점은 마크 후에 쓰레기를 삭제할때, 삭제만 하는게 아니라 생존한 객체들을 한쪽으로 예쁘게 모은다는 것이다.

이를 통해서 파편화 문제를 해결한다.

바로 이놈이 이른바 Stop the World를 유발하는 주범이다. 메모리 이동은 필연적으로 메모리 접근을 차단한 채로 이뤄져야하기 때문이다.

그래서 예전에는 GC로 인한 정지시간이 초 단위로 간 적도 있는데, 요즘은 이런저런 최적화를 많이 해서 10ms 정도의 지연이 보장된다.

Mark and Copy 알고리즘

객체가 많아질수록 느려지는 마크앤스윕을 개선하기 위해 나온 알고리즘이다.

1969년에 로버트 페니첼이란 사람이 고안했다.

V8에서는 신세대 메모리 GC(Minor GC)에 Mark and Copy를 사용한다.

이 기법에서는, 우선 메모리를 2개로 쪼갠다.
그리고 한번에 한 블록만 사용한다.

그러다 한쪽이 꽉차면 살아남은 객체만 다른 블록으로 옮기고 기존 블록을 싹 지워버린다.

대부분의 객체가 살아남는다면 다 옮겨야하니 복사비용이 꽤 들지만, 대다수가 죽는 경우라면 놀라울 정도로 효율적인 결과를 낼 수 있다.

게다가 옮기는 과정에서 새 블록에 차곡차곡 예쁘게 쌓아서 파편화 문제도 없다.

물론 단점도 명백하다.

1. 객체 생존률이 높다면 비효율적이다.
   그래서 V8에서는 생존률이 낮을거라 예상되는 신세대 영역에만 사용한다.

2. 메모리를 반토막내서 쓰는거라 가용 메모리 낭비가 심하다.
   JVM에서는 Eden-Survivor라는 변칙적인 방법으로 이런 메모리 낭비를 최소화했는데, 사실 V8에는 이런 고민의 흔적이 없다. 그냥 반토막내서 쓴다.

Orinoco 프로젝트

V8 GC는 매우 불안정하고 느린 시기가 있었다.
그 중에서도 mark와 sweep, compact 과정동안 Stop the world를 너무 오랫동안 때릴 수 있는 문제가 있었다.
상황이 나쁘면 무려 초단위로까지 지연됐다.

이걸 해결하기 위해 V8는 GC에 대한 최적화 프로젝트를 진행했다. 이게 Orinoco다.

orinoco에서 진행한 최적화 관점 3가지를 간단히 정리해보겠다.

Increment 최적화
GC를 한번에 다 처리하기보단, 그냥 적당히 잘라서 천천히 치우는 형태로 발전했다.

https://v8.dev/blog/trash-talk
이건 Go GC와 거의 동일한 접근법이다.

메모리 정리에 걸리는 최종적인 완료 시간은 더 길어질 수 있지만, 당장 멈추는 간격들 자체는 줄일 수 있었다.
이것으로 V8 GC는 어지간해서 5-10ms 정도의 정지시간을 보장할 수 있다.
Increment함을 보장하기 위해서 V8도 GoGC처럼 Tri-Color 알고리즘을 사용한다.

https://v8.dev/blog/concurrent-marking

Parellel 처리
그리고 당연히 스레드도 돌릴만큼 돌린다.

각자가 GC 작업을 서로 분할해서 처리하는 것이다.
JS는 언어가 싱글스레드인거지, GC 자체에는 코어를 꽤 활용한다.

Concurrency
그리고 실제 GC 스레드와 메인 프로그램 스레드가 어느 정도는 동시적으로 돈다.

GC가 도는 동안 무조건 메인스레드를 차단하지는 않는 것이다.
물론 완전히 차단시간이 없을 수는 없고, 차단이 발생하는 스텝이 있고 잠깐동안 차단하는 스텝이 있고 그런거다.
그래서 엄밀히 말하면 사실 저 그림은 틀렸다.

Idle time GC 스케줄링 (브라우저)

Node.js를 제외하고, 크롬 같은 브라우저에 해당되는 이야기다.

웹게임이나 미디어 처리 같은 처리속도가 매우 중요한 시스템을 만든다면 밀리초 수준의 지연 시간도 치명적으로 다가올 수 있다.

게다가 위에서 V8 GC의 평균 정지시간이 5-10ms 정도라고 했지만, 최악의 상황에는 정지시간이 100ms 수준으로 지연될 수도 있다.

근데 크롬의 렌더링 주기는 60FPS(초당 60번)이다.
16.6ms 이내에 렌더링을 완료해야 한다는 것이다.

이 때 잠재적인 문제는, 렌더링 시기에 GC가 돌아서 리소시를 점유하고 마감 시간인 16.6ms 이내에 렌더링을 완료하지 못하는 경우다.
이러면 해당 프레임이 결국 삭제되고, 사용자에게 좋지 않은 경험을 줄 수 있다.
이 현상을 jank라고 부른다.

V8은 이런 문제를 해결하기 위해서 좀 복잡한 방법을 추가로 사용한다.
크롬의 스케줄러까지 활용해서 화면에 프레임을 그리지 않는 idle 타임 내에 GC를 수행하도록 하는 것이다.

https://queue.acm.org/detail.cfm?id=2977741
일반적으로 프레임 렌더링 간격 내에서 완벽하게 끝낼 수 있다면 그렇게 하고, 16ms가 넘더라도 실질적인 화면 업데이트가 이루어지지 않았다면 GC를 좀 더 오래 돌리기도 한다.
그래도 사용자 입력에 대응하기 위해 보통 50ms를 상한선으로 두는 편이다.

이를 통해서 V8은 jank 문제를 꽤 해소한다.
이를 통해 일반적으로 70% 정도의 GC는 프레임 렌더링 사이의 Idle 타임에 처리된다.

참조
https://fe-developers.kakaoent.com/2022/220519-garbage-collection/
https://jayconrod.com/posts/55/a-tour-of-v8-garbage-collection
https://v8.dev/blog/trash-talk
https://queue.acm.org/detail.cfm?id=2977741