20210914 Garbage Collection

토론 주제

Garbage Collection은 컴퓨터 메모리 관리 기법 중 하나로, 동적으로 할당했던 메모리 영역 중에서 필요없게 된 영역을 해제하는 기능입니다.

하지만 이 가비지 컬렉션의 단점으로

• 첫째, 어떤 메모리를 해제할지, 언제 해제할지 결정하는 오버헤드가 일어납니다.
• 둘째, 컬렉션이 일어나는 타이밍이나 점유시간을 예측하기 어려워 일시적으로 프로그램이 정지되곤 합니다.
• 셋째, 할당된 메모리가 해제되는 시점을 알 수 없습니다.

이 단점 중 한가지를 정해, 자신만의 아이디어로(자료구조를 더하든지, 알고리즘을 짜든지) 단점을 해결하는 방안을 수립하여 설명해주세요.

토론 내용

서그림

첫번째 단점에 대하여
참고 : [Java] Garbage Collection(가비지 컬렉션)의 성능을 높이는 코딩 방법

어떤 메모리를 해제할지 결정하는 부분에 있어서 개발자의 입장으로 해결할 수 있는 부분을 생각해보았습니다. 언어는 Java입니다.

• Java Collection API를 사용할 때, 그 크기를 예측할 수 있다면 생성 시에 직접 설정해주는 것이 좋습니다. 예를 들어 ArrayList의 경우, 크기를 설정해주지 않는다면 정해진 크기의 배열을 새로 생성하고 붙여주는 식으로 구현됩니다. 이 경우 사용하지 않는 크기에 대해서도 배열이 생성되어 가비지가 발생합니다.
• Stream을 사용하여 일정한 chunk 만큼씩 데이터를 조회하도록 합니다. 데이터의 크기가 너무 크다면 OutOfMemoryErrors가 발생할 수 있습니다. 따라서 Stream을 사용하여 Buffer를 재사용함으로써 OutOfMemoryErrors를 방지하고 가비지의 생성을 최소화할 수 있습니다.
• 불변성을 활용하여 코딩합니다. Java에서 객체를 그대로 넘겨주고 넘겨주는 방식으로 코딩을 하다보면, 그 규모가 커졌을 때 여러 함수들이 객체를 참조하고 있는 상태가 되기 때문에 가비지 컬렉터가 스캔해야 하는 객체의 수가 늘어납니다. 불변성을 사용하여 새로운 객체를 리턴하는 방식으로 코딩을 하면 스캔해야 하는 메모리 영역과 빈도수가 줄어들어 성능을 높일 수 있습니다.

---

정희재

가비지 컬렉션 은 어떻게 동작하는가

• Heap 공간이 Eden, Survivor1, Survivor2, Old 구역으로 나누어져서 관리됩니다. 새로운 객체가 생성되면 Eden에 저장되고, Eden이 꽉차면 Mark and Sweep이 진행됩니다. 이 과정에서 살아남은 객체들은 Survivor1으로 이동됩니다. Survivor1이 꽉차면 역시 Mark and Sweep 진행 후 Survivor2로 이동되고, Survivor2가 꽉차면 역시 같은 과정을 거친 후 다시 Survivor1으로 이동합니다. Survivor1과 Survivor2로 이동을 특정 횟수 만큼 반복하고 나면 Old로 이동하게 됩니다. Old가 꽉차게 되면 Mark and Sweep 과정을 진행하고 비워진 공간들을 채우기 위해 Compaction이 진행됩니다. 이 Compaction 과정에서 가비지 컬렉션 스레드를 제외한 모든 스레드들이 일시 중지됩니다.

Mark and Sweep: 더 이상 참조되지 않는 객체(쓰레기 값)를 찾아내고 비워내는 과정

스레드가 일시 중지되는 현상을 최소화 하려면 어떻게 해야할까?

• 가장 직관적인 방법으로는 가비지 컬렉션이 발생하는 횟수를 줄이는 것입니다. 개발할 때 더이상 사용되지 않는 객체는 직접 메모리를 해제 해주어 가비지 콜렉터가 하게되는 일의 양을 줄여 줍니다. 다만 가비지 컬렉션을 지원하는 Java의 경우는 메모리를 부분적으로 직접 해제 해주는 기능이 아직 구현되어 있지 않습니다.
• Old 구역의 공간이 꽉 찼을 때 Mark and Sweep을 진행한 후 Compaction 과정을 실행하지 않습니다. 스레드를 일시 중지 시키는 근본적인 원인을 해결하는 것입니다. 다만 이럴 경우 Old 구역에 단편화가 발생하게 됩니다. 이를 해결하기 위해 단편화가 발생한 위치와 비어있는 메모리 조각의 크기를 저장하고 있다가 Old 구역에 새로운 객체 할당 시 참조하여 넣어줍니다. 추가적인 메모리가 발생한다는 단점이 있지만 스레드가 중지되는 상황을 방지할 수 있을 것이라는 의견입니다.

---

권혁진

자바스크립트의 경우 필요하지 않은 메모리를 판별하는 것은 참조 여부에 의해 진행됩니다. 이러한 가비지(더 이상 쓰이지 않는 오브젝트)를 판단하는 데에는 여러 알고리즘이 있습니다.

참고 : 자바스크립트 MDN 가비지컬렉션

Reference-Counting 알고리즘

어떤 다른 오브젝트도 참조하지 않은 오브젝트가 차지하고 있는 메모리를 가비지로 규정합니다.

하지만, 두 객체가 서로 참조하며 순환하는 구조를 이룰 때 가비지로 인식되지 않는 한계가 있습니다.

Mark-and-Sweep 알고리즘

더 이상 닿을 수 없는 오브젝트 를 가비지로 규정합니다. 이를 위해 root 라는 오브젝트의 집합을 사용합니다.

root가 참조하는 오브젝트, root가 참조하는 오브젝트가 참조하는 오브젝트...

이러한 방식으로 닿을 수 있는 오브젝트와 그렇지 않은 오브젝트로 이분화하고 닿을 수 없는 오브젝트에 대해 가비지 컬렉션을 수행합니다.

위의 Reference-Counting 알고리즘과 다르게 순환 참조에 대한 문제가 발생하지 않습니다.

2012년 기준 모든 최신 브라우저는 가비지 콜렉션에서 이 방식을 사용한다고 합니다.

하지만 개발자가 직접 가비지 콜렉션을 핸들링 하지는 못합니다.

결국 메모리가 언제 해제되는가? 에 대한 질문의 완벽한 답을 얻을 수는 없었습니다.
개발자가 메모리 해제 시점을 수동으로 결정할 수 없으니, 그림님이 언급한 방식처럼 `메모리 누수`를 방지하며 가비지를 미리 예방하는 코딩 습관을 갖는게 중요하다고 생각합니다.

---

장주섭

첫번째와 두번째 문제는 최소화는 가능하나 완전한 해결은 불가능 할 것으로 보이고 세번째 문제는 오버헤드는 발생하더라도 완전한 해결이 가능할 것으로 보아 선택하였습니다.

1. (적합한) 일정한 주기마다 해제를 진행하고 해제되는 시점을 기록한다.
2. 검은색(사용중), 회색(아직 검사 미진행), 흰색(미사용) 을 사용하는 삼색표기기법을 활용한다.
3. 흰색 대신 몇번째 가비지 컬렉션에서 해당 메모리가 해제되었는지 기록한다.
4. 이러한 정보(주기, 몇번째 가비지컬렉션인지)를 토대로 언제 메모리가 해제되었는 지 확인 가능하다.

문제점 : 흰색이란 정보 대신 얼만큼 늘어날지 모르는 정수를 정보를 가져야한다는 점과 적절한 주기를 어떻게 설정할 것인지에 대한 문제점이 존재합니다.

결론 : 가비지 컬렉션 주기를 어느정도 파악하고 정보기록에 늘어나는 메모리보다 해제되는 시점을 추적하는게 중요한 문제라면 적용해볼만한 방안이라고 생각합니다.

토론 결과

가비지 컬렉션의 내부 구조에 대해 알아볼 수 있는 시간이었습니다. 이에 대해서 생각해보는 것만으로 의미있는 시간이었지만, 개발자로서 할 수 있는 좋은 방법은 가비지 컬렉션의 성능을 고려한 코딩 방법입니다. 따라서 가비지 컬렉션에 대해 알고 있으며 그를 고려한 코딩 방식을 익히자는 결론이 나왔습니다.