Dalvik VM: GC Heap에 대한 Overview
Dalvik VM은 Java VM과 마찬가지로 garbage collection되는 heap을 제공한다. 즉, 할당된 메모리에 대해 명시적으로 메모리 해지를 할 필요가 없다.
하지만, Dalvik GC heap의 내부 구현을 들여다보면 기존 Sun JDK가 제공하던 GC heap과는 상당히 다른 구현방법을 따르고 있음을 알 수 있다. 이런 차이로 Java 코드 작성 시 주의해야 할 점이 생긴다. 이 글에서는 Dalvik의 GC heap의 구조와 객체가 생성되어 메모리를 할당받는 방식에 대해 살펴보도록 하겠다. (실제 garbage collection이 이루어지는 과정에 대해서는 다음 글에서 다루도록 한다.)
HeapSource *heapSource;
heapSource 에는 GC Heap이 사용하는 메모리 공간에 대한 정보를 저장한다. Heap 메모리의 포인터, 초기 크기, 최대 크기 등의 정보를 관리한다. GC Heap에서 사용되는 Heap 메모리는 dlmalloc이라는 오픈소스 메모리 관리자를 사용하여 구현되어 있다. dlmalloc의 create_mspace 함수를 호출하여 생성된 mspace 포인터를 HeapSource로 관리한다.
HeapRefTable nonCollectableRefs;
nonCollectableRefs는 GC 수행 시 삭제되어서는 안 되는 객체들의 목록을 유지한다. 삭제되지 않는 객체는 dvmMalloc으로 메모리 할당 시 ALLOC_NO_GC 속성을 주어서 만들 수 있다. Dalvik 코드를 보면 생성 중인 쓰레드가 중간에 garbage collection 되어 사라지는 경우가 발생하지 않도록 이 속성을 이용하여 메모리를 할당하고 쓰레드 생성이 모두 완료되면 dvmClearAllocFlags 함수를 호출하여 쓰레드 객체에 대해 ALLOC_NO_GC 속성을 지워버리게 구현되어 있다.
LargeHeapRefTable *finalizableRefs;
finalizableRefs에는 finalization이 필요한 Java 객체의 목록을 유지한다. finalization이 필요한 객체란 Object의 public void finalize() 메쏘드를 override 해서 구현한 객체를 뜻한다. GC에 의해 객체가 정리될 때 해당 객체의 finalize() 메쏘드를 호출하여 마지막으로 사용한 자원을 정리할 기회를 제공한다.
enum { SR_COLLECT_NONE, SR_COLLECT_SOME, SR_COLLECT_ALL }
softReferenceCollectionState;
softReferenceCollectionState은 SR_COLLECT_NONE, SR_COLLECT_SOME, SR_COLLECT_ALL 중 하나의 값을 가지는 enum 타입이다. 이 값은 GC 중 SoftReference 정리에 대한 규칙을 나타낸다. 객체에 대해 SoftReference를 유지하면 만일, VM에 메모리가 절대적으로 부족한 상태가 되면 해당 객체가 비록 reference가 유지된 상태지만 GC 처리해서 메모리에서 제거 가능토록 한다. 주로, cache를 구현하기 위해 자주 사용하는 기능이다.
SR_COLLECT_NONE 이면 SoftReference 참조 객체를 GC 처리하지 않고 SR_COLLECT_ALL 이면 모든 SoftReference 참조 객체들을 GC 대상으로 삼는다.
Object *softReferences;
Object *weakReferences;
Object *phantomReferences;
앞에서 설명한 SoftReference된 객체는 위에 보이는 멤버 변수에 관리된다. 이 목록은 매번 GC가 수행될 때 새로 만들어진다.
Object* dvmAllocObject(ClassObject* clazz, int flags);
함수 원형을 보면 1번째 인자가 생성하려는 객체의 클래스 정보이고 2번째 정보는 ALLOC_NO_GC와 같은 속성값을 지정할 수 있다. dvmAllocObject 함수는 객체에 필요한 메모리 공간을 할당받기 위해 dvmMalloc 함수를 호출한다.
void* dvmMalloc(size_t size, int flags);
dvmMalloc 함수는 다시 tryMalloc 함수를 호출하여 GC Heap에서 객체에 필요한 메모리 공간을 얻으려 한다. tryMalloc 함수는 아래와 같은 순서대로 메모리 공간을 최대한 할당받기 위해 노력하며 모든 방법이 다 실패하면 NULL을 반환한다.
하지만, Dalvik GC heap의 내부 구현을 들여다보면 기존 Sun JDK가 제공하던 GC heap과는 상당히 다른 구현방법을 따르고 있음을 알 수 있다. 이런 차이로 Java 코드 작성 시 주의해야 할 점이 생긴다. 이 글에서는 Dalvik의 GC heap의 구조와 객체가 생성되어 메모리를 할당받는 방식에 대해 살펴보도록 하겠다. (실제 garbage collection이 이루어지는 과정에 대해서는 다음 글에서 다루도록 한다.)
GcHeap - Garbage Collected Heap 구조체
Dalvik 은 내부 Heap을 관리하기 위해 GcHeap이라는 구조체를 사용한다. 이 구조체의 주요 멤버 변수들을 살펴보면서 GC Heap의 디자인에 대해 살펴보도록 하자.HeapSource *heapSource;
heapSource 에는 GC Heap이 사용하는 메모리 공간에 대한 정보를 저장한다. Heap 메모리의 포인터, 초기 크기, 최대 크기 등의 정보를 관리한다. GC Heap에서 사용되는 Heap 메모리는 dlmalloc이라는 오픈소스 메모리 관리자를 사용하여 구현되어 있다. dlmalloc의 create_mspace 함수를 호출하여 생성된 mspace 포인터를 HeapSource로 관리한다.
| (참고. dlmalloc 이란?) dlmalloc은 State University of New York at Oswego 교수님이신 Doug Lee가 작성한 오픈소스 메모리 관리자이다. Doug Lee가 Solaris나 기존 UNIX 환경에서 사용하던 메모리 관리자에 불만을 느끼고 성능 및 fragmentation 이슈를 최소화한 메모리 관리자를 목표로 개발한 오픈소스 코드이다. Android는 GC Heap에서 객체를 allocation하고 free 하는 등의 메모리 관리를 모두 dlmalloc에 의존하고 있어 dlmalloc의 수행 성능이 매우 중요하다. |
HeapRefTable nonCollectableRefs;
nonCollectableRefs는 GC 수행 시 삭제되어서는 안 되는 객체들의 목록을 유지한다. 삭제되지 않는 객체는 dvmMalloc으로 메모리 할당 시 ALLOC_NO_GC 속성을 주어서 만들 수 있다. Dalvik 코드를 보면 생성 중인 쓰레드가 중간에 garbage collection 되어 사라지는 경우가 발생하지 않도록 이 속성을 이용하여 메모리를 할당하고 쓰레드 생성이 모두 완료되면 dvmClearAllocFlags 함수를 호출하여 쓰레드 객체에 대해 ALLOC_NO_GC 속성을 지워버리게 구현되어 있다.
LargeHeapRefTable *finalizableRefs;
finalizableRefs에는 finalization이 필요한 Java 객체의 목록을 유지한다. finalization이 필요한 객체란 Object의 public void finalize() 메쏘드를 override 해서 구현한 객체를 뜻한다. GC에 의해 객체가 정리될 때 해당 객체의 finalize() 메쏘드를 호출하여 마지막으로 사용한 자원을 정리할 기회를 제공한다.
enum { SR_COLLECT_NONE, SR_COLLECT_SOME, SR_COLLECT_ALL }
softReferenceCollectionState;
softReferenceCollectionState은 SR_COLLECT_NONE, SR_COLLECT_SOME, SR_COLLECT_ALL 중 하나의 값을 가지는 enum 타입이다. 이 값은 GC 중 SoftReference 정리에 대한 규칙을 나타낸다. 객체에 대해 SoftReference를 유지하면 만일, VM에 메모리가 절대적으로 부족한 상태가 되면 해당 객체가 비록 reference가 유지된 상태지만 GC 처리해서 메모리에서 제거 가능토록 한다. 주로, cache를 구현하기 위해 자주 사용하는 기능이다.
SR_COLLECT_NONE 이면 SoftReference 참조 객체를 GC 처리하지 않고 SR_COLLECT_ALL 이면 모든 SoftReference 참조 객체들을 GC 대상으로 삼는다.
Object *softReferences;
Object *weakReferences;
Object *phantomReferences;
앞에서 설명한 SoftReference된 객체는 위에 보이는 멤버 변수에 관리된다. 이 목록은 매번 GC가 수행될 때 새로 만들어진다.
| WeakReference는 SoftReference보다 더 약한 연결 고리라고 생각할 수 있다. SoftReference로 참조된 객체는 VM에 메모리가 절대적으로 부족한 사항이 되기 전에는 그 참조가 유지된다. 그러나, WeakReference로 참조된 객체는 GC가 발생하면 현재 메모리 상태에 상관없이 바로 메모리에서 정리될 수 있다. GC에 의해 특정 객체가 finalize 되었는데 만일 이 객체에 대해 PhantomReference가 설정되어 있었다면 이 객체를 메모리에서 바로 정리하지 않고 PhantomReference Queue에 참조를 등록하여 코드에서 접근할 수 있도록 한다. 객체의 자원 정리를 구현하기 위해 사용할 수 있다. |
GC Heap에서 메모리 할당받기 - dvmMalloc 함수
dvmAllocObject 함수를 이용하여 Dalvik VM에 새로운 객체를 생성할 수 있다.Object* dvmAllocObject(ClassObject* clazz, int flags);
함수 원형을 보면 1번째 인자가 생성하려는 객체의 클래스 정보이고 2번째 정보는 ALLOC_NO_GC와 같은 속성값을 지정할 수 있다. dvmAllocObject 함수는 객체에 필요한 메모리 공간을 할당받기 위해 dvmMalloc 함수를 호출한다.
void* dvmMalloc(size_t size, int flags);
dvmMalloc 함수는 다시 tryMalloc 함수를 호출하여 GC Heap에서 객체에 필요한 메모리 공간을 얻으려 한다. tryMalloc 함수는 아래와 같은 순서대로 메모리 공간을 최대한 할당받기 위해 노력하며 모든 방법이 다 실패하면 NULL을 반환한다.
- dvmHeapSourceAlloc 함수를 호출하여 객체에 필요한 메모리 할당을 시도한다.
- 만일 위 과정이 실패하면 gcForMalloc(false)를 호출하여 strong reference에 대해서만 GC를 수행하고 다시 dvmHeapSourceAlloc를 호출하여 메모리 할당을 시도한다.
- 위 과정이 실패하면 dvmHeapSourceAllocAndGrow 함수를 호출하여 GC Heap 크기 자체를 늘리도록 한 후 메모리 할당을 시도한다.
- 아직도 실패한다면 gcForMalloc(true)를 호출하여 soft reference까지 포함하여 GC를 수행하고 다시 메모리 할당을 해본다.
- 위 과정이 모두 실패한다면 Out Of Memory 예외가 발생할 것이다.
댓글
댓글 쓰기