[Python] GC의 구조

20세기말-21세기에 나온 대부분의 언어가 그렇듯이, 파이썬 또한 런타임 GC에 의해 메모리가 관리되는 언어다.

Python도 구현체마다 GC 원리가 다른데, 여기서는 CPython을 기준으로 정리한다.

Python의 GC는 다른 언어들에 비하면 전반적으로 엉성하거나 부실한 부분이 많다.
그래서 메모리 압력이 심한 장기실행형 프로그램에는 별로 적절하지 않다.

Reference Counting

파이썬은 기본적으로 Reference Counting 기반으로 메모리의 할당을 관리한다.

원리는 C++의 shared_ptr, Rust의 Rc, Swift의 기본 포인터와 거의 동등하다.

https://www.codementor.io/@arch/variable-references-in-python-u9z8j2gk0
포인터 객체 내부에 참조 갯수를 저장하고, 포인터가 복제될때마다 카운트를 증가, 복제된 변수가 해제될때마다 카운트를 감소시켜서 0이 되면 객체를 파괴하는 정책이다.

구현 자체가 단순하고 GC에 비하면 공간 효율성이나 실행속도가 좋다는 장점이 있다.

문제는, 상호참조가 발생하는 상태에서의 처리가 매우 어렵다는 것이다.
Reference Count는 변수가 "해제될때" 카운트를 감소시켜서 파괴하는 것인데, 서로가 서로를 참조하는 상황에서는 해제가 트리거되지 않아서 무한 대기상태에 빠질 수 있다.

https://velog.io/@snack/OS-ARCAutomatic-Reference-Counting
A와 B 변수가 둘다 해제되더라도, A는 B가 해제되지 않았으니 카운트가 1이고, B도 A가 아직 해제되지 않았으니 카운트가 1인 끝없는 수렁에 빠지는 것이다.

그래서 C++/Rust/Swift 같은 경우는 참조 개수에 포함되지 않는 Weaked Pointer 단위를 만들어서 문제를 조금 복잡하게 해결한다.

하지만 Python은 여기서 GC 스텝을 추가하는 것으로 누수를 피한다.

왜 Reference Counting인가?

보통 GC가 달린 언어들은 mark and sweep 기반의 기술들만을 활용해서 GC를 구현한다.
Reference Counting과 Mark and Sweep을 스까서 만드는 경우가 흔치는 않다.

Reference Counting를 포기하지 않고 GC를 우겨넣은 것에는 역사적인 이유가 있다. 그리고 그 중 하나는 하위호환이다.
RC는 실제 코드에 삽입되는 동작이므로 섣불리 제거한다면 바이너리 호환성이 깨질 수 있기 때문이다.

Reference Counting 기반으로 구현한 데서 나오는 장점도 있다.
순환참조가 일어나지 않는다는 가정 하에서는 메모리의 해제가 거의 즉시 일어난다는 것이다. Stop the World 문제도 적다.

세대별(Generational) GC

대다수의 GC 언어들은 세대별 GC 이론을 기본으로 사용한다. 파이썬도 마찬가지다.

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

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

이러한 경험에 힘입어 파이썬도 신세대와 구세대를 별도의 공간에 저장하며 관리한다.
계속해서 살아남을 확률이 높은 객체만 구세대 영역에 모아두고, 나머지를 신세대에 두고서 집중하는 것이다.

세대 구분은 닷넷처럼 0, 1, 2의 3가지다.
0세대에서 시작해서 한번 생존하면 1, 두번 생존하면 2세대로 가는 형태다.

0세대는 위에 설명했던 Reference Count 기반으로 처리가 되는 대상이다. 그래서 1세대로 가는건 순환참조로 걸리는 경우다.
1세대와 2세대에 대해서는 Mark and Sweep 기반으로 GC를 처리한다.

Mark and Sweep 알고리즘

현대 GC의 근간이 된 기법 중 하나다.
1960년에 리습의 창시자 매카시가 만들었다.

Java에서도 몇몇 GC 기법은 마크앤 스윕 기반으로 만들어졌고, 파이썬은 지금도 이걸 쓴다.

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

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

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

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

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

게다가 메모리 파편화도 심하다. 그냥 일단 지우고 보는게 최종 목적이기 때문에 메모리 조각모음같은걸 고려하지도 않았다.

메모리 파편화가 누적될수록 연속된 큰 공간이 없어져서 빈 공간을 찾기도 힘들고, 추가적인 정리작업이 필요해질 수도 있다.

Memory Compaction 없음

파이썬은 메모리 단편화를 해결하기 위한 솔루션을 전혀 사용하지 않았다.

보통의 GC 언어들은 Mark and Sweep과 동시에 memory compaction을 수행해서 정지시간이 생기는 대신에 메모리 단편화를 막는데, 파이썬은 그런게 없다.
Stop the World가 적은 대신, 장기실행형 프로그램이라면 메모리 단편화로 메모리 할당 문제가 생길 수 있다.

GIL(Global Interpreter Lock)

GIL은 Python의 원죄 중 하나다.

이건 사실 구현을 단순화하기 위해서 벽을 쳐두고 멀티스레드나 기타 성능 최적화에서의 손실을 감수한 것에 가깝다.
그래서 현재는 GIL을 제거하려고 시도는 하고 있으나, 얼마나 잘 될지는 잘 모르겠다.

아무튼 현재 Python의 GC도 GIL에 의존하는 부분이 많다.

GIL의 큰 존재목적 중 하나는 Reference Count를 처리할 때의 효율성과 안전성을 유지하기 위한 것이다.

카운트 값을 멀티스레드에서도 유효하게 만들려면 추가적인 동기화나 락 작업이 필요한데, 그걸 하지 않는 대신에 싱글스레드로 고정해버린 것이다.

참조
https://stackoverflow.com/questions/21934/why-java-and-python-garbage-collection-methods-are-different
https://www.winterjung.dev/python-gc/
https://stackoverflow.com/questions/9062209/why-does-python-use-both-reference-counting-and-mark-and-sweep-for-gc
https://dev.to/karishmashukla/how-python-uses-garbage-collection-for-efficient-memory-management-270h
https://velog.io/@vhzpt109/Python-Garbage-Collector%EC%97%90-%EB%8C%80%ED%95%9C-%EA%B3%A0%EC%B0%B0
https://devguide.python.org/internals/garbage-collector/index.html
https://stackoverflow.com/questions/59118749/python-gc-memory-compaction