Garbage Collector

EXEM Knowledge Base

(CMS Collector에서 넘어옴)
Jump to: navigation, 찾기

Java 프로그래밍 언어는 메모리를 직접 할당하고 해제하는 기능을 제공하지 않는다. Java가 구동되는 실행 환경인 JVM(Java Virtual Machine)은 자동화된 메모리 관리 기능을 제공하며, 대부분의 JVM들이 Garbage Collection기법을 이용하고 있다.

Garbage Collection을 수행하는 모듈 또는 쓰레드를 Garbage Collector라고 부른다. Garbage Collector는 Application이 생성한 객체의 생존 여부를 판단해서 더 이상 사용되지 않는 객체를 해제함으로써 메모리 관리가 자동화되도록 한다.

Garbage Collection의 효율성이 Application의 성능에 큰 영향을 미치기 때문에 각 JVM이 어떤 종류의 Garbage Collector들을 제공하는지 정확하게 이해해야 한다.


목차

[편집] Throughput vs. Response Time

흔히 "성능"을 개선시킨다는 것은 다음과 같은 두 가지를 의미한다.

  • Throughput 개선: 얼마나 많은 량의 일을 처리할 수 있느냐가 성능 개선의 기준이 된다.
  • Response Time 개선: 작업 처리 요청에 대해 얼마나 응답을 빨리 하느냐가 성능 개선의 기준이 된다.


JVM이 제공하는 Garbage Collector들도 위의 두 기준을 사용한다. 즉 특정 Garbage Collector는 Throughput의 최대화를 목적으로, 또 다른 Garbage Collector는 Response Time의 최적화를 목적으로 작동한다. Throughput과 Response Time의 두가지 목적은 상호 배반적인 성격을 지니고 있다. 따라서 Application의 요구 사항에 따라 최적의 Garbage Collector를 선택해야 한다.


[편집] Sun HotSpot JVM

Sun HotSpot JVM은 Generation에 기반한 Heap 구조를 사용한다. Geneation 기반의 Heap 구조는 Heap을 Young Generation이 거주하는 New SpaceTenured Generation이 거주하는 Old Space로 나누어 관리한다.

Sun HotSpot JVM 계열에서는 다음과 같은 종류의 Garbage Collector를 제공한다.

[편집] Serial Collector

JDK 1.4까지의 기본(Default) Collector이다. 1.5 부터는 기본 Collector로 어떤 Collector를 사용할 지를 JVM이 결정한다. CPU가 2장이상, 메모리가 2G 이상인 "서버"급 머신에서는 Parallel Collector가 선택되며, "클라이언트"급 머신에서는 Serial Collector가 선택된다. UseSerialGC 옵션을 이용해 강제로 지정할 수 있다.

[편집] Throughput Collector(Parallel Collector)

Young Generation에 대한 Minor GC 작업을 병렬로 처리함으로써 GC 성능을 높인다. UseParallelGC 옵션에 의해 활성화된다. Throughput, 즉 처리량을 최대화하는데 목적이 있다.
JDK 1.5부터는 Server 급 머신일 경우에는 Parallel Collector가 Default Collector이다. Server 급 머신이란 2장 이상의 CPU, 2G 이상의 Physical Memory를 갖춘 머신을 의미한다.

[편집] Concurrent Low Pause Collector(CMS Collector)

Old Generation에 대한 GC 작업을 Application Thread와 동시에(Concurrent) 진행한다. UseConcMarkSweepGC 옵션에 의해 활성화된다. Concurrent GC 작업은 GC Pause 시간을 줄임으로써 Response Time을 개선시키지만 Throughput은 다소 줄어들 수 있다.
CMS CollectorConcurrent GC 작업은 Old Generation에 대한 GC 작업에만 영향을 준다.

[편집] IBM JVM

IBM JVM은 Sun HotSpot JVM과는 달리 Generation 기반의 Heap 구조를 사용하지 않는다. 즉, Single Space로 이루어진 Heap 구조를 사용한다. 단, JDK 1.5 버전부터는 Sun HotSpot JVM과 동일한 방식의 Generation Heap 구조를 부가적으로 지원한다.

IBM JVM 계열에서는 다음과 같은 종류의 Garbage Collector를 제공한다.

[편집] Throughput Collector

기본(Default) Collector이다. Throughput을 최적화하는 방식으로 동작한다. gcpolicy(-Xgcpolicy:optthruput) 옵션에 의해 활성화된다. IBM JVM은 기본적으로 Generation을 사용하지 않는다. 따라서 Young GenerationOld Generation의 구분이 없으며, Minor GCMajor GC의 구분도 없다. 단, JDK 1.5에서 도입된 Concurrent Generational Collector를 사용하면 Sun Hotspot JVM과 동일한 방식, 즉 Generation에 기반한 Heap 관리 기법을 사용한다.

Throughput Collector에 의한 Heap 관리 기법을 정리해보면 다음과 갈다.

  • Young GenerationOld Generation의 구분이 없이 하나의 Heap 영역으로 관리된다.
  • 일반적인 GC 작업은 기본적으로 Mark and Sweep 작업만을 수행한다. 즉 Compaction 작업은 수행하지 않는다.
  • Mark and Sweep 만으로 메모리를 확보하지 못하는 경우에는 Compaction 작업이 수행된다. Compaction 작업은 Sun Hotspot JVM에서의 Full GC와 동일한 방식이다. 즉 모든 Application Thread를 Stop 시키고 Compaction을 수행한다.

[편집] Response Time Collector

Throughput Collector와는 달리 응답시간을 최적화하는 방식으로 동작한다. gcpolicy(-Xgcpolicy:optavgpause) 옵션에 의해 활성화된다.

Response Time Collector에 의한 Heap 관리 기법을 정리하면 다음과 같다.

  • Young GenerationOld Generation의 구분없이 하나의 Heap 영역으로 관리된다.
  • Concurrent Mark 작업과 Concurrent Sweep 작업이 추가적으로 발생한다. 즉, Concurrent Mark -> Mark & Sweep(STW) -> Concurrent Sweep의 단계로 GC가 발생하며 이로 인해 Mark and Sweep에 의한 Application Stop 시간을 최소화할 수 있다. 단, 그만큼 Throughput은 감소한다.
  • Compaction 작업은 Throughput Collector와 동일한 방식으로 동작한다.

IBM JVM의 Response Time Collector는 Sun Hotspot JVM의 CMS Collector와 매우 흡사하다. 각 JVM 벤더들이 서로의 장점을 흡수하면서 생기는 자연스러운 현상이라고 볼 수 있다.

[편집] Concurrent Generational Collector

1.5에서 추가된 Collector로, Sun HotSpot JVM과 같은 방식, 즉 Generation에 기반한 Heap 관리 기법을 제공한다. Sun Hotspot JVM의 CMS Collector와 동작 방식이 거의 유사하다. gencon(-Xgcpolicy:gencon) 옵션에 의해 활성화된다.

[편집] SubPool Collector

Java Heap을 여러 개의 Sub Pool로 나누어 관리하는 기법을 사용한다. 16 CPU 이상의 서버 환경에서만 사용할 것을 권장한다. subpool(-Xgcpolicy:subpool) 옵션에 의해 활성화된다.

[편집] BEA JRockit JVM

BEA JRockit JVM 계열에서의 Garbage Collector 분류 방법은 다른 JVM보다 좀 더 복잡하다. JRockit JVM에서는 "GC 우선 순위"와 "GC 모드"의 조합에 따라 Garbage Collector를 구분한다.

[편집] GC 우선 순위에 따른 구분

[편집] Throughput Collector

Throughput을 최적화하는 방식으로 동작한다. -Xgcprio:throughput 옵션에 의해 할성화된다. 최초 구동시에는 Single-spaced Parallel GC 모드로 동작하지만, 런타임에 GC 모드가 변경될 수 있다.

[편집] Pausetime Collector

Pause Time을 최적화하는 방식으로 동작한다. -Xgcprio:pausetime 옵션에 의해 활성화된다. 최초 구동시에는 Single-spaced Concurrent GC 모드로 동작하지만, 런타임에 GC 모드가 변경될 수 있다.

[편집] GC 모드에 따른 구분

[편집] Single-spaced Parallel Collector

Heap을 Single Space로 관리하며 Parallel 하게 GC 작업을 수행한다. IBM JVM의 Throughput Collector와 거의 동일한 방식이다. -Xgc:singlecon 옵션에 의해 활성화된다.

[편집] Single-spaced Concurrent Collector

Heap을 Single Space로 관리하며 Concurrent하게 GC 작업을 수행한다. IBM JVM의 Response Time Collector와 거의 동일한 방식이다. -Xgc:parallel 옵션에 의해 활성화된다.

[편집] Generational Concurrent Collector

Generation에 기반해서 Heap를 관리한다. IBM JVM의 Generational Concurrent Collector와 거의 동일한 방식이다. -Xgc:gencon 옵션에 의해 활성화된다.

[편집] HP-UX HotSpot JVM

HP-UX의 HotSpot JVM은 Sun HotSpot JVM과 거의 동일한 기능을 제공한다.

[편집] 관련 정보

  1. Sun HotSpot JVM의 Heap 관리 기법
  2. IBM JVM의 Heap 관리 기법

[편집] 외부 참조

  1. Sun JDK 6.0 Troubleshooting Guide
  2. Sun JDK 5.0 Troubleshooting Guide
  3. IBM JDK 5.0 Diagnostics Guide