JVM은 현재 정기적으로 미사용 객체가 있는 힙을 통해서 찾고, 그 객체가 점유하고 있는 메모리를 해제하고 추가 객체를 할당하는 데 사용한다.
하지만 이렇게 메모리를 해제하고 사용하지만 GC는 어떤 메모리를 해제할지, 언제 해제할지 결정하는 오버헤드가 일어난다.
또, 컬렉션이 일어나는 타이밍이나 점유시간을 예측하기 어려워 일시적으로 프로그램이 정지된다. 마지막으로, 할당된 메모리가 해제되는 시점을 알 수 없다는 큰 세가지의 단점이 존재한다. 이를 해결하기 위한 방법을 설명해보자.
실제로 GC 튜닝이 존재할정도로 GC의 단점은 부각되어 왔었고 운영중인 시스템마다 적합한 GC 방식을 추려내고, 선택하여야 한다고 생각한다.
그럼에도 위 세가지 단점 중 ' 어떤 메모리를 해제할지, 언제 해제할지 결정'하는 오버헤드가 개발자의 입장에서 단점을 최소화할 수 있을 것이라고 생각한다.
근본적으로, 이러한 단점들은 GC를 최소화하고, 최적화하여 사용하는 것이 메모리 관리 차원에서 효율적이란 것으로 귀결된다. 그 이유는 GC가 작동하면 작동할수록 '오버헤드'가 일어나고, 일어나는 타이밍이나 점유시간을 예측하기 어렵기 때문에 일시적으로 중지되기 때문이다.
객체로 접근할 수 있는 경로가 남아있지 않게 객체의 참조를 null값을 이용하여 끊어주는 것이 가장 GC를 최소화하는 방법 중 하나이고 실제로 Rust의 경우는 참조를 빌려주게 되면 다시 해당 스코프로 반환하는 다양한 바인딩 방법으로 언제 객체를 해지되어야 할 지 정확히 알려주며 활용하고 있다.
하지만 위는 GC를 활용하는 방법보다는 '개발자의 입장에서'를 주로 생각하고 있어서 단점을 최소화하는 방법으로는 어울리지 않는다.
' 나의 의견 '
'프로그램이 일시적으로 정지되는 시간을 최소화시킨다'
G1GC는 전체 힙 메모리 영역을 Region이라는 특정한 크기로 나눠 각 Region의 상태에 따라 그 Regin에 역할이 동적으로 부여되는데,
G1GC의 성능이 효율적이라고 알려져 있는 것에서 착안하여 나의 생각으로는 Heap Area를 '우선순위 Heap Set'으로 나누는 것을 생각하였다. 일반적으로 가비지컬렉션이 일어날 곳과, 일어나지 않아도 될 곳을 구분해줌으로써 근본적 오버헤드를 줄여 정지시간을 최소화시키는것이 방법이다. 맨 처음 객체가 생성이 되면 Eden 영역에 생성이 되고, 아직 사용된다고 판단되는 객체들을 Survivor1, Survivor2 영역으로 이동시키며 일정 score을 누적시키는데 정해진 score 이상이 되면 score들을 기준으로 나누어 우선순위가 높은 Region으로 움직여줄것이다. 이렇게 되면 예상되는 문제점으로는 GC대상을 파악하는 과정이 여러단계로 수행되어 CPU 사용량이 높다는 것이다.
Garbage Collection
동적으로 할당했던 메모리 영역 중 필요 없게 된 메모리 영역을 해제하는 기능
JVM은 현재 정기적으로 미사용 객체가 있는 힙을 통해서 찾고, 그 객체가 점유하고 있는 메모리를 해제하고 추가 객체를 할당하는 데 사용한다.
하지만 이렇게 메모리를 해제하고 사용하지만 GC는 어떤 메모리를 해제할지, 언제 해제할지 결정하는 오버헤드가 일어난다. 또, 컬렉션이 일어나는 타이밍이나 점유시간을 예측하기 어려워 일시적으로 프로그램이 정지된다. 마지막으로, 할당된 메모리가 해제되는 시점을 알 수 없다는 큰 세가지의 단점이 존재한다. 이를 해결하기 위한 방법을 설명해보자.
실제로 GC 튜닝이 존재할정도로 GC의 단점은 부각되어 왔었고 운영중인 시스템마다 적합한 GC 방식을 추려내고, 선택하여야 한다고 생각한다.
그럼에도 위 세가지 단점 중 ' 어떤 메모리를 해제할지, 언제 해제할지 결정'하는 오버헤드가 개발자의 입장에서 단점을 최소화할 수 있을 것이라고 생각한다.
근본적으로, 이러한 단점들은 GC를 최소화하고, 최적화하여 사용하는 것이 메모리 관리 차원에서 효율적이란 것으로 귀결된다. 그 이유는 GC가 작동하면 작동할수록 '오버헤드'가 일어나고, 일어나는 타이밍이나 점유시간을 예측하기 어렵기 때문에 일시적으로 중지되기 때문이다.
객체로 접근할 수 있는 경로가 남아있지 않게 객체의 참조를 null값을 이용하여 끊어주는 것이 가장 GC를 최소화하는 방법 중 하나이고 실제로 Rust의 경우는 참조를 빌려주게 되면 다시 해당 스코프로 반환하는 다양한 바인딩 방법으로 언제 객체를 해지되어야 할 지 정확히 알려주며 활용하고 있다.
하지만 위는 GC를 활용하는 방법보다는 '개발자의 입장에서'를 주로 생각하고 있어서 단점을 최소화하는 방법으로는 어울리지 않는다.
' 나의 의견 '
'프로그램이 일시적으로 정지되는 시간을 최소화시킨다'
G1GC는 전체 힙 메모리 영역을 Region이라는 특정한 크기로 나눠 각 Region의 상태에 따라 그 Regin에 역할이 동적으로 부여되는데,
G1GC의 성능이 효율적이라고 알려져 있는 것에서 착안하여 나의 생각으로는 Heap Area를 '우선순위 Heap Set'으로 나누는 것을 생각하였다. 일반적으로 가비지컬렉션이 일어날 곳과, 일어나지 않아도 될 곳을 구분해줌으로써 근본적 오버헤드를 줄여 정지시간을 최소화시키는것이 방법이다. 맨 처음 객체가 생성이 되면 Eden 영역에 생성이 되고, 아직 사용된다고 판단되는 객체들을 Survivor1, Survivor2 영역으로 이동시키며 일정 score을 누적시키는데 정해진 score 이상이 되면 score들을 기준으로 나누어 우선순위가 높은 Region으로 움직여줄것이다. 이렇게 되면 예상되는 문제점으로는 GC대상을 파악하는 과정이 여러단계로 수행되어 CPU 사용량이 높다는 것이다.
더 좋은 근본적인 방법이 없을까?......