데블스캠프2017/InternalOfJavaScriptCore'sGarbageCollector: Difference between revisions

Revision as of 04:24, 1 July 2017

Garbage Collector

메모리 관리를 런타임에 자동으로 해주는 시스템
최초의 구현은 1958 년도 LISP

GC vs Manual

프로그래머의 생산성
프로그램의 효율성
- - 메모리 관리자의 처리량 + 정지 시간
  - 공간 오버헤드

=> 연구 결과를 통해서 성능차이가 없는 것을 증명했다. (단, 메모리를 5배 정도 더 줄 때)
=> 보통의 경우 17%의 오버헤드가 있다.
=> Manual 하게 할 때도 오버헤드는 있다.

Definitions

Heap

프로그램 사용 영역

Roots

javascript 로 따지면 windows 같은 것,  절대로 해제가 안될 것, global하게 노출되어 있는 것

Collector
Mutators

Object Liveness

Dead : 안쓰고 있는 메모리
Live : 사용하고 있는 메모리
- True liveness => 실제로 판별하기 굉장히 어려움
- Pointer reachability => 대부분의 경우 이 방식

Mark-Sweep GC

간접적인 GC 알고리즘
Dead 오브젝트가 아닌 Live 오브젝트들을 모두 추적
나머지 Garbage 로 결정
JSC 에서도 이 알고리즘을 사용

javascript도 이 방식을 사용한다.

Mark

root 에서 도달 가능한 것을 Mark

Sweep

Mark 단계에서 체크되지 않은 것들은 도달할수 없기 때문에 삭제

메모리를 많이 쓸 수록 느려짐 => 메모리를 적게 쓰는 경우일수록 효율적

@@ Line 1: / Line 1: @@
-= 서기 =
+__TOC__
-이곳에 적어주세요
+== Contents ==
+* GC 의 개요
+* JSC(WebKit) 의 GC 구현
+* 메모리 누수 사례
+== Garbage Collector ==
+* 메모리 관리를 런타임에 자동으로 해주는 시스템
+* 최초의 구현은 1958 년도 LISP
+== GC vs Manual ==
+* 프로그래머의 생산성
+* 프로그램의 효율성
+*** 메모리 관리자의 처리량 + 정지 시간
+*** 공간 오버헤드
+ => 연구 결과를 통해서 성능차이가 없는 것을 증명했다. (단, 메모리를 5배 정도 더 줄 때)
+ => 보통의 경우 17%의 오버헤드가 있다.
+ => Manual 하게 할 때도 오버헤드는 있다.
+== Definitions ==
+* Heap
+ 프로그램 사용 영역
+* Roots
+ javascript 로 따지면 windows 같은 것,  절대로 해제가 안될 것, global하게 노출되어 있는 것
+* Collector
+* Mutators
+== Object Liveness ==
+* Dead : 안쓰고 있는 메모리
+* Live : 사용하고 있는 메모리
+** True liveness => 실제로 판별하기 굉장히 어려움
+** Pointer reachability => 대부분의 경우 이 방식
+== Mark-Sweep GC ==
+* 간접적인 GC 알고리즘
+* Dead 오브젝트가 아닌 Live 오브젝트들을 모두 추적
+* 나머지 Garbage 로 결정
+* JSC 에서도 이 알고리즘을 사용
+ javascript도 이 방식을 사용한다.
+=== Mark ===
+ root 에서 도달 가능한 것을 Mark
+=== Sweep ===
+ Mark 단계에서 체크되지 않은 것들은 도달할수 없기 때문에 삭제
+* 메모리를 많이 쓸 수록 느려짐 => 메모리를 적게 쓰는 경우일수록 효율적