JVM 알아보기

JVM이란

자바 가상 머신의 약자로 자바 바이트코드를 실행하는 주체이다. 플랫폼에 독립적이며(특정 플랫폼에 귀속되지않는다는 의미) 정해진 규격을 따라서 자바 바이트코드를 실행한다. 즉, API를 동일하게 맞춘 상태에서 이론적으로 CPU나 OS에 무관하게 똑같이 작동한다는 이야기다.

 

P-code(스택에 피연산자 타입 기술)와 스몰토크(GC, OOP) VM에 영향을 받아 스택기반으로 설계되었다. P-code는 type-safe 하지 않아 메모리 내용을 망칠 수 있었고, 스몰토크 역시 동적타입 방식을 사용해서 플랫폼에 따라 타입의 형태가 달라지는 경우가 생겼다. jvm은 모든 기본타입의 정의를 명확히함으로써 이런 모호함을 줄였다.

 

즉, 결론은 jvm은 OS-사용자 사이의 중간 매개 역할을 한다. 사용자의 자바 파일을 자바 컴파일러가 컴파일하면 jvm이 읽을 수 있는 형태인 .class(바이트 코드 파일)로 변경되고 이걸 jvm이 OS가 이해할 수 있게 해석해준다. JRE는 자바 런타임 환경의 약자로 자바클래스를 jvm으로 동적로드하는 환경 전체를 의미한다.

 

자바 클래스 로더는 JRE의 일부인데 파일과 파일 시스템 관련 작업을 클래스로더에서 처리해준다. 모든 자바 클래스는 클래스로더에 의해 로드된다. 자바로 작성되기 때문에 사용자가 직접 클래스로더를 만들 수도있다. 클래스 로더는 라이브러리를 찾아 내용을 읽고, 그 안에 포함된 클래스들을 또 읽는 역할을 한다. 프로그램의 요청(호출)이 있기전에는 로드 작업을 수행하지않는다.

 

jvm이 시작되면 3가지 클래스 로더가 사용된다.

1. 부트스트랩 클래스 로더 - %JAVA_HOME%/jre/lib을 읽는다.
2. 확장 클래스 로더 - %JAVA_HOME%/jre/lib/ext에 위치한 확장 디렉터리를 읽는다.
3. 시스템 클래스 로더 - 환경변수에 의해 맵핑된다.

아래는 자바 SE7 기반 JVM 아키텍처 도식이다.

JVM 메모리 구조를 한번 기억할 필요가 있을 것 같다.

 

Execution Engine은 자바 바이트코드를 명령어 단위로 한줄 씩 읽어서 실행한다. PC 레지스터는 쓰레드와 관련된 부분이다. 쓰레드가 생성될 때 마다 생성되는 공간으로 각 쓰레드마다 하나 씩 존재한다. 현재 수행 중인 jvm 명령어의 주소를 갖고 쓰레드가 어떤 부분에서 어떤 명령어를 실행할지에 대한 기록을 수행한다. 힙 영역은 GC가 담당하는 부분이다.

GC - Garbage Collection

가비지 콜렉션/콜렉터라고 부르는 이 방법은 동적으로 할당한 메모리영역 중 필요없게 된 영역을 해제하는 메모리 관리 기법 중 하나다. 동적할당영역을 관리하기 때문에 주로 힙 메모리에서 작동한다. 자바는 GC를 지원하기 때문에 C/C++과 같이 프로그래머가 메모리영역 전체를 완전히 관리할 필요가 없다.

 

컬렉팅할때 사용되는 기법은 포인터 추적 방식이 일반적이다. 이 방식은 한 개 이상의 변수가 접근가능한 메모리는 앞으로 사용할 수 있는 메모리(가용)로 간주하고, 그 외의 메모리를 해제하는 방식이다. 이때 접근 가능한 메모리는 직/간접적으로 접근가능한 객체로 정의 할 수 있는데, 지역변수와 전역변수를 포함한다. 이 객체가 가리키는 모든 객체도 접근 가능하다고 한다. 이게 간접적인 접근인데 재귀로 받아들이면 된다.

프로그램에서 최근에 할당된 영역이 더 먼저 해제될 확률이 높다는 관찰이 있었는데, 세대단위 수집방식(Weak Generation Hypothesis)은 할당된 시간대를 각 세대로 구분해서 세대별로 서로 다른 메모리영역에 객체를 할당한다. 한 세대의 메모리 영역이 다 차면, 이 영역에서 살아있는 객체를 더 이전세대의 메모리영역으로 옮긴다.

 

오래된 영역에서는 객체가 변하지않을 확률이 높다는 점을 이용한 것이다. 이러면 메모리의 일부 영역만을 주기적으로 수집하게 되므로 성능이 올라간다. 자바를 포함해 현대적 언어 대부분에서 이 기법을 사용한다. 그림을 보면 Young 영역과 Old 영역, Permanent 영역이 있다. Permanent 영역은 말이 그렇지 그냥 메소드 영역이라고도 하며 문자열 정보를 저장하는 곳이다. 당연히 GC가 발생할 수 있다.

 

Young 영역에서 제거될 때를 Minor GC, Old 영역에서 제거될 때를 Major GC(Full GC)가 발생한다고 말한다. Old에 있는 객체가 Young에 있는 객체를 참조하게 되면 이 경우를 카드테이블(Old영역에 512byte 짜리 덩어리)에 기록해서 Young에서 삭제할때 Old영역 전체에서 찾지않고 카드테이블에서 찾아 GC처리한다.

 

다른 포인터 추적 기법으로 mark and sweep, 삼색표시 기법, 객체이동기법과 같은 방식이 존재한다.

 

다른 수집방식으로는 참조횟수 계산 방식이 있는데 각 객체의 참조 횟수를 기억해서 참조횟수가 0이라면 사용이 끝났다는 의미가 되므로 그 객체를 해제하는 방식이다. 이 방식의 장점은 접근불가해지는 시점에 바로 메모리에서 해제되니까 해제 시점을 예측할수 있다는 점이고, 단점이라면 두 객체가 서로를 가리키고 있는 순환참조라고 하는 상황, 참조횟수가 0이될때 참조하고있는 객체들 또한 0으로 만드는 연쇄 작업과 같은 문제가 있다는 점이다. 파이썬에서 이 방식을 사용한다고 한다.

 

GC가 있으면 다음과 같은 버그를 잡을 수 있다

• 유효하지 않은 포인터 접근 - 이미 해제된 메모리에 접근
• 이중 해제 - 이미 해제된 메모리를 또 해제하는 시도
• 메모리 누수 - 더이상 필요없는 메모리가 해제되지 않고 남아있는 상태(공간차지)

GC를 사용하면서 생기는 문제점이라고 한다면 메모리 해제 시점을 추적하기위해 필요한 오버헤드, 컬렉팅 시점, 점유시점을 예측하는게 어렵다는 점(리얼타임 시스템에서는 부적합한 작동방식이다.), 할당된 메모리가 해제되는 시점을 알 수 없다는 점이다. 즉 3가지 모두 자원해제에 관련해서 발생하는 문제인데 사용자가 직접 메모리관리를 온전히 하는 게 아니기에 발생하는 단점이라고 할 수 있겠다.

 

또 GC를 실행할 때 JVM이 애플리케이션 실행을 멈추는 stop-the-world가 발생하는데 GC를 실행하는 쓰레드를 제외한 나머지 쓰레드를 모두 멈추는 것이다. GC가 완료되면 재개되는데 이 시간을 줄이는 것을 GC 튜닝이라고 대부분 칭한다고 한다.

---

참조:

자바 가상 머신 - 위키백과, 우리 모두의 백과사전

쓰레기 수집 (컴퓨터 과학) - 위키백과, 우리 모두의 백과사전

참조 횟수 계산 방식 - 위키백과, 우리 모두의 백과사전

NAVER D2

도움이 됐다면 댓글이나 공감 버튼 한 번씩 누르고 가주세요! 로그인 안해도 됩니다 ^_^