Difference between r1.2 and the current
@@ -1,7 +1,6 @@
[[Tableofcontents]]
== Contents ==
* GC 의 개요
* JSC(WebKit) 의 GC 구현
* 메모리 누수 사례
== Contents ==
* JSC(WebKit) 의 GC 구현
* 메모리 누수 사례
@@ -11,7 +10,6 @@
* 최초의 구현은 1958 년도 LISP
== GC vs Manual ==
* 프로그래머의 생산성
* 프로그램의 효율성
* 메모리 관리자의 처리량 + 정지 시간
== GC vs Manual ==
* 프로그램의 효율성
* 메모리 관리자의 처리량 + 정지 시간
@@ -22,7 +20,6 @@
=> Manual 하게 할 때도 오버헤드는 있다.
== Definitions ==
* Heap
프로그램 사용 영역
* Roots
== Definitions ==
프로그램 사용 영역
* Roots
@@ -31,7 +28,6 @@
* Mutators
== Object Liveness ==
* Dead : 안쓰고 있는 메모리
* Live : 사용하고 있는 메모리
* True liveness => 실제로 판별하기 굉장히 어려움
== Object Liveness ==
* Live : 사용하고 있는 메모리
* True liveness => 실제로 판별하기 굉장히 어려움
@@ -43,13 +39,46 @@
* 나머지 Garbage 로 결정
* JSC 에서도 이 알고리즘을 사용
* JSC 에서도 이 알고리즘을 사용
* 메모리를 많이 쓸 수록 느려짐 => 메모리를 적게 쓰는 경우일수록 효율적
javascript도 이 방식을 사용한다.=== Mark ===
root 에서 도달 가능한 것을 Mark
=== Mark 단계 ===
* root 에서 도달 가능한 것을 Mark
=== Sweep ===
Mark 단계에서 체크되지 않은 것들은 도달할수 없기 때문에 삭제
=== Sweep 단계 ===
* Mark 단계에서 체크되지 않은 것들은 도달할수 없기 때문에 삭제
=== Lazy Sweep ===
* 한번 Dead 오브젝트가 되면 영원히 Dead
* mutator 들은 mark-bit에 접근할 수 없다
* '''Sweep 오퍼레이션은 병렬로 실행해도 괜찮다'''
* 보다 간단한 해결책으로 allocate 함수에서 sweep 수행
=== Generation GC ===
* 약한 세대 가설 => 75~95% 객체가 10KB 이내에 죽는다.
* 메모리를 많이 쓸 수록 느려짐 => 메모리를 적게 쓰는 경우일수록 효율적
=== Mark-Sweep GC 특징 ===
* 뮤테이터 오버헤드가 작다
* 공간 오버헤드가 참조 카운팅보다 적다
* lazy sweep 과 조화시키면 전체 처리량도 좋은 편
* 힙에 충분한 여유공간을 필요로 한다
== JSC 의 가비지 컬렉터 구현 ==
* 발표 ppt 참조
=== Eden collection ===
* JSC 에서는 힙 공간을 물리적으로 나누지 않는다
* 그냥 root 셋에서부터 도달 가능한 객체들만 marking 하고 종료
* Sweep 은 allocation 시점에 lazy-sweep
* marking 된 객체를 Old gen 으로 간주
=== Full collection ===
* Eden collection 수행 후 잔여 힙 크기가 30% 미만일 경우 다음 GC를 full collection 으로 예약
* 페이지가 변경될 때 WebCore 에서 Full collection 을 요청
* marking 전에, 모든 블록의 mark bitmap 을 초기화
* 이후 동작은 eden collection 과 유사
=== JSC GC 세줄 요약 ===
1. MarkedSpace::clearMarks()
2. JSC::visitChildren()
3. sweep()
3. GC vs Manual ¶
- 프로그래머의 생산성
- 프로그램의 효율성
- 메모리 관리자의 처리량 + 정지 시간
- 공간 오버헤드
=> 연구 결과를 통해서 성능차이가 없는 것을 증명했다. (단, 메모리를 5배 정도 더 줄 때) - 메모리 관리자의 처리량 + 정지 시간
=> 보통의 경우 17%의 오버헤드가 있다.
=> Manual 하게 할 때도 오버헤드는 있다.
4. Definitions ¶
- Heap
프로그램 사용 영역
- Roots
javascript 로 따지면 windows 같은 것, 절대로 해제가 안될 것, global하게 노출되어 있는 것
- Collector
- Mutators
5. Object Liveness ¶
- Dead : 안쓰고 있는 메모리
- Live : 사용하고 있는 메모리
- True liveness => 실제로 판별하기 굉장히 어려움
- Pointer reachability => 대부분의 경우 이 방식
- True liveness => 실제로 판별하기 굉장히 어려움
6. Mark-Sweep GC ¶
- 간접적인 GC 알고리즘
- Dead 오브젝트가 아닌 Live 오브젝트들을 모두 추적
- 나머지 Garbage 로 결정
- JSC 에서도 이 알고리즘을 사용
- 메모리를 많이 쓸 수록 느려짐 => 메모리를 적게 쓰는 경우일수록 효율적
javascript도 이 방식을 사용한다.
6.3. Lazy Sweep ¶
- 한번 Dead 오브젝트가 되면 영원히 Dead
- mutator 들은 mark-bit에 접근할 수 없다
- Sweep 오퍼레이션은 병렬로 실행해도 괜찮다
- 보다 간단한 해결책으로 allocate 함수에서 sweep 수행
6.5. Mark-Sweep GC 특징 ¶
- 뮤테이터 오버헤드가 작다
- 공간 오버헤드가 참조 카운팅보다 적다
- lazy sweep 과 조화시키면 전체 처리량도 좋은 편
- 힙에 충분한 여유공간을 필요로 한다
7.1. Eden collection ¶
- JSC 에서는 힙 공간을 물리적으로 나누지 않는다
- 그냥 root 셋에서부터 도달 가능한 객체들만 marking 하고 종료
- Sweep 은 allocation 시점에 lazy-sweep
- marking 된 객체를 Old gen 으로 간주
