JVM_17_GC 다시 알기 (수정사항)

 

 

1. GC 는 reachable 만 남기는 것

GC 이름대로 unreachable이 중요한 것이 아니라 reachable한 객체를 어떻게 남기는 지가 중요한 것

살아있는 객체를 어떻게 살릴것인지가 관건입니다.

Oracle의 GC 개발자가 만든 유튜브 영상 확인하기

 

 

2. Compact 단계에서의 메모리 압축

메모리를 압축하는 것이 아닙니다.

4bite 간격으로 데이터를 정렬/쌓는 과정입니다.

 

3. Heap 의 크기  Young 영역이 Old 영역보다 크다.

Young 영역이 작아서 속도가 빠른 것이 아닙니다.

Young 영역에 reachable로 남는 객체가 적어 비교적 가벼워 처리 속도가 빠른것입니다.

상대적으로 Old 영역 내에 reachable 객체가 많아 속도가 비교적 느린 것입니다.

Young 영역 70% , Old 영역 30%

G1 GC가 사용되기 좋은 상황 중
"힙 크기가 최대 수십 GB 이상이며 Java 힙의 50% 이상이 살아있는 객체로 채워지는 경우"

여기에서 힙의 50% 이상이 살아있어도 문제가 되지 않는다는 부분에서 Young 영역이 Old 영역보다 작다고 할 수 없다.

Young 영역의 Survivor 0 & Survivor 1 영역 10% (각 5%정도)
Eden 영역이 훨씬 크다.
Old 영역은 reachable 객체가 많아 MinorGC가 불필요합니다.
ex)
Spring Singleton 객체
일반적으로 애플리케이션의 전체 라이프사이클동안 존재합니다.
이러한 싱글턴 객체는 Spring의 애플리케이션 컨텍스트에 의해 관리됩니다.
컨텍스트 초기화 시 생성되어 애플리케이션 종료 시점까지 유지됩니다.
그러나 객체는 JVM의 메모리 관리 과정에 따라 Young 영역을 거쳐 Old 영역으로 이동합니다.
싱글턴 객체의 경우 애플리케이션의 라이프사이클 동안 지속적으로 사용되므로 Old 영역으로의 프로모션이 일찍 일어날 수 있습니다.
효율적인 메모리 사용을 위함이며 자주 접근되는 객체에 빠르게 접근할 수 있어 GC의 오버헤드도 줄일 수 있습니다.

 

 

4. STW > GC만 실행하면 되는데 왜 스레드를 실행하고 멈춰야 하는지

Young 영역이 작아서 속도가 빠른 것이 아닙니다.

Young 영역에 reachable로 남는 객체가 적어 비교적 가벼워 처리 속도가 빠른것입니다.

상대적으로 Old 영역 내에 reachable 객체가 많아 속도가 비교적 느린 것입니다.이전에 실행된 스레드에서 사용하던 객체를 다음 실행할 스레드에서 사용할 수도 있기 때문에 GC 전에 사용되던 reachable Object를 사용할 수도 있습니다.
스레드를 실행하지 않고 GC만 실행하는 경우 다시 로드해야 하는 일이 발생할 수 있습니다.

 

 

5. Space Reclamation에서 STW가 필요한 이유

새로 생성되는 객체 때문은 아닙니다.
복사되는 과정에서 변경되는 내용이 있을수도 있으므로 STW가 필요합니다.

 

`1234` 인 객체가 복사되는 과정에서 `12`까지 복사한 시점에 `ABCD`로 변경된 경우 GC 이후 값을 확인하면 값이 `12CD`와 같이 변경값이 적용되지 않을 수 있음

 

이러한 일이 발생하는 이유는 개발자가 GC를 통제하지 못하기 때문에 발생하는 것으로 볼 수 있습니다.
Rust의 경우 STW 를 하지 않는 다는 것이 중점인데 이는 제어가 가능하기 때문입니다. (소유권을 단 하나만 가질 수 있기 때문)
Java는 모두 가리킬 수 있어 가능성이 있는 모든 객체를 멈춰두고 실행하는 것입니다.
GO 의 경우 GC가 있어도 STW를 하지 않을 수도 있습니다.

 

5. Space Reclamation에서 STW가 필요한 이유

새로 생성되는 객체 때문은 아닙니다.
복사되는 과정에서 변경되는 내용이 있을수도 있으므로 STW가 필요합니다.