• JS, HTML/CSS, Python, Java, PHP 등 많은 언어에서 GC 채택
• 자바 애플리케이션 - 대부분 객체 수명 매우 짧음 → GC가 나온 이유

G1 GC

• JDK 9 Default
• 높은 처리량 + 낮은 STW(Stop The World) 지향
• 영역크기 - 최대 heap 사이즈에 따라 결정
• STW: 리마킹, 클린업 등 사이클 내에서 총 3번 발생
  • Heap 메모리 충분치 않을 경우, 객체 복사공간 없어서 실패
  • GC가 완료되어도 공간 없을 경우 Full GC 수행
  • 거대 객체가 처음에 발생할 경우, 남는공간이 발생해 메모리 단편화 발생
    • 거대 객체는 full gc 발생해도 옮겨지지 않음

ZGC

• 대용량 힙 사이즈

• 저지연

  • 중단 시간 최대 1ms

• 오토 튜닝 (손쉬운 설정)

• JDK 11 Experimental, JDK 15 Release

• ZPage : ZGC 메모리 관리 단위

• G1과 달리 세대로 구분하지 않고 객체 크기에 따라 분할

  • Small: 2MB
  • Medium: 2~32MB (최대 힙의 3.125%)
  • Large: Medium 페이지보다 큰 객체(가변적으로 크기 할당) → 거대 객체 이슈 해결

• Colored Pointer

  • Unused (16 bits)
  • 컬러비트 (4개 중 1개 bit만 1로 설정)
    • F
    • R
    • M (1)
    • M (0)
  • Object Address

• Multi-Mapping

  • 하나의 물리 메모리에 3개의 가상 메모리 주소가 매핑됨
  • RSS over-reporting 부작용
    • 실제 물리 메모리 사용량보다 RSS가 3배 크게 관측됨
    • 실제론 더 적게 사용하므로 문제되는 상황은 아니나, Cloud 환경이라면 오인돼 OOM Killer에 의해 정리될 수 있음
      • Generational ZGC부터는 Multi-Mapping 사용하지 않아 해결됨