CS/Android, Kotlin

[Android] AOS ART, Garbage Collector 방식

dongdong216 2023. 4. 7. 22:52

Android

  • Linux 기반
  • ART(Android Runtime)이 java로 돌아가므로 메모리 감독도 Java 방식을 사용

 

ART?

  • ART는 Android 5.0 (API 레벨 21) 이상이 실행되는 기기의 기본 런타임. 이 런타임은 Android 플랫폼과 앱의 성능, 유연성을 개선하는 수많은 기능을 제공. 안드로이드에서 사용되던 Dalvik VM의 한계점을 극복하기 위해 새로 개발된 런타임
  • ART의 기능 중 하나인 가비지 컬렉션(GC) 개선
    GC는 리소스 집약적이므로 앱 성능을 저하시켜 화면 끊김, UI 응답성 부족 등의 문제가 일어남. ART에서는 백그라운드 메모리 사용량 및 조각화를 줄이기 위한 동시 복사, 단일 GC 일시중지가 있는 동시 실행 설계… 등의 방법으로 GC를 개선
  • ART 방식?
    machine 위에서 AOT 파일을 돌리는 방식임
    앱을 설치할 때 완전히 Machine code로 변환되어 설치됨 (AOT, Ahead-Of-Time 컴파일)
    장점은 코드 Interpret, JIT compile 시간을 제거하여 performance 향상이지만 단점은 설치 시점에 소스 코드를 번역하기에 설치가 느리고 파일을 따로 저장하기에 용량이 커지게 됨
    • AOT Compiler?
      프로그램 설치 시 컴파일러를 제외한 소스코드를 로드
      추가 컴파일 작업 없이 바로 실행이 가능함
      사용자의 대기 시간이 거의 없음
      설치 시 컴파일 된 파일을 따로 저장하기 때문에 프로그램 크기가 증가
    • JIT compiler
      중간 언어(bytecode)를 읽지 않고 프로그램이 실행될 때 한꺼번에 읽어서 번역을 진행함
      인터프리터 방식에 비해 10~20배 정도의 성능 개선
      배터리 소모가 많아짐, 한 번에 읽는 방식이라 화면 전환 시 속도가 느림

 

자바 Garbage Collector 동작 방식?

자바의 가비지 컬렉터는 여러 종류가 있지만 공통적으로 두 가지의 작업을 수행함

  1. 힙 내의 객체 중 Garbage를 찾아냄
  2. 찾아낸 Garbage 객체를 반환하여 메모리를 회수함

위 과정을 자세히 적으면 다음과 같음. 객체들은 일단 생성되면 힙 영역에 생성됨. 그런데 힙에 새로운 객체를 생성했을 때 공간이 부족하다면 JVM은 Out of MemoryGC를 뿌리게 됨 GC는 Root Set of References(유효한 최초의 참조)가 이루어지지 않는 Unrechable Objects를 수거함. GC는 이 객체들을 메모리에서 제거하기 전에 해당 객체의 finalize() 메소드를 호출함.

 

자바의 이전 GC 방식

1. Marking : 프로세스는 마킹을 호출하여 GC가 메모리가 사용되는지 아닌지 체크하는 과정. 참조되는 객체는 파란색, 참조되지 않는 객체는 주황색으로 보여짐 모든 오브젝트는 마킹 단계에서 스캔됨 → 많은 시간을 소모

2. Normal Deletion : 위에서 칠한 참조되지 않는 객체인 주황색 부분을 모두 제거하고 메모리를 반환함. 메모리 Allocator는 반환 후 빈 블럭의 참조 위치를 저장한 후 새로운 오브젝트가 선언되면 그 부분을 할당해줌.

3. Compacting : 퍼포먼스 향상을 위해 참조되지 않은 객체를 제거하고 남은 참조되고 있는 객체들을 묶음이들을 묶어서 공간이 생기므로 새로운 메모리 할당 시 더 쉽고 빠르게 진행할 수 있음

 

Generational Garbage Collection

모든 객체를 Mark & Compact하는 JVM은 비효율적임. 오브젝트를 할당할 때마다 GC 시간에 오브젝트의 리스트를 읽는 시간은 점점 길어짐. 그러나 경험적 분석에 의하면 대부분의 객체는 짧게 생존함. (시간이 지날수록 적은 객체만 남게됨) 따라서 아래와 같이 Young, Old, Permanent로 나눔.

  1. Young generation : 새롭게 생성한 객체의 대부분이 여기에 위치함. 가득차게 되면 minor garbage collection이 일어나게 됨. 대부분 객체가 금방 사라지기 때문에 많은 객체가 이 영역에서 사라짐.
  2. Old generation : 접근 불가능 상태가 되지 않고 Young 영역에서 살아남은 객체들이 복사가 됨. Young 영역보다 크기가 크고 GC는 적게 발생함. 이 영역에서 객체가 사라질 때 Major GC라고 함.
  3. Permanent generation : Method Area라고도 함. JVM이 클래스들과 메소드들을 설명하기 위해 필요한 메타 데이터들을 포함하고 있음.

 

Generational Garbage Collection 동작 과정

이미지  설명
1. 어떠한 새로운 오브젝트가 들어오면 Eden Space에 할당함
2. Eden space가 가득차면 minor garbage collection이 시작됨
3. 참조되는 오브젝트들은 첫 번째 survivor(s0)로 이동되고 비 참조 객체는 Eden space가 clear될 때 반환함
4. 다음 minor GC 때 Eden Space에서는 같은 일이 일어남. 비 참조 객체는 삭제 되고 참조 객체는 survivor space로 이동. 그러나 이 두 번째의 minor GC 때 참조 객체들은 두 번째 survivor space로 이동. 그리고 최근 minor GC에서 첫 번째 survivor space로 이동된 객체들의 age도 증가하고 두 번째 survivor space로 이동하게 됨 이런 과정이 끝나면 s0, eden space는 clear 됨. 그림을 보면서 이해하면 수월함. 
5. 다음 minor GC 때도 같은 과정이 발생하기는 함. 그러나 이번엔 survivor space가 switch 됨. 참조되는 객체들은 s0로 이동 살아남은 객체들은 다 aged 됨. → 비슷하게 eden과 s1 space는 clear 됨.
6. promotion 과정. minor GC 후 aged 오브젝트들이 일정한 age threshold 값을 넘게 되면 young generation에서 old로 promotion 되어짐. 이 예시에서는 age threshold 값이 8임.
7. minor GC가 계속되고 객체들이 점점 old generation으로 이동함. 이러다가 major GC가 일어나게 되면 old generation의 space도 clear 되고 공간이 compact해지게 됨.

 

 

 

저작자표시 (새창열림)