[Become a Java-Masta👨‍🏫 1주차] JVM과 자바 코드

🎯 목표

자바 소스 파일(.java)을 JVM으로 실행하는 과정 이해하기.

📌 학습할 것

• JVM이란 무엇인가
• 컴파일 하는 과정
• 컴파일 및 실행하는 방법
• 바이트코드란 무엇인가
• JIT 컴파일러란 무엇이며 어떻게 동작하는지
• JVM 구성 요소
• JDK와 JRE의 차이

💡 JVM이란 무엇인가

일반적인 프로그램은 Windows 또는 Linux와 같은 운영체제 위에서 실행이 된다. 즉, 아래와 같은 구조로 실행이 된다.

위 그림에 보이듯이 일반적인 프로그램은 하드웨어를 기반으로 운영체제가 동작을 하고, 그 위에서 프로그램이 실행되는 구조이다.

그러나 자바 프로그램은 아래와 같이 일반 프로그램과는 다른 구조로 실행이 된다.

그림을 보았듯이 자바 프로그램이 일반 프로그램과 비교해서 가장 큰 차이점은 운영체제와 자바 프로그램 사이에 자바 가상머신(JVM)이 존재하는 점이다.
즉 운영체제가 바로 프로그램일 실행시키는 것이 아니라, 운영체제는 JVM을 실행하고 JVM이 자바 프로그램을 실행시키는 구조이다.

그렇다면 JVM은 무엇이며, 자바 프로그램은 일반 프로그램과 같이 운영체제가 직접 프로그램을 실행시키는 구조를 따르지 않고 왜 JVM 위에서 동작하는 것인가?

일단 JVM도 다른 프로그램과 마찬가지로 운영체제 위에서 동작하는 소프트웨어이다. 자바 프로그램을 실행시키는 소프트웨어인 것이다.
이렇게 자바 프로그램이 JVM 위에서 동작하는 구조의 이유는 자바 프로그램을 운영체제와 상관없이 동작시키기 위함 이다.

프로그램은 운영체제에 따라서 달리 구현되어야 한다. 예를 들어 우리가 노션이라는 프로그램을 다운받을 때, 운영체제가 Windows인지 Mac인지 구분하여 프로그램을 다운받는다.
Windows에서 동작하도록 구현된 노션을 다운받으면 절대 Mac에서 설치할 수 없다.

따라서 동일한 기능의 노션이라 할지라도 Mac에서 동작을 시키려면 Mac을 기반으로 다시 구현해주어야 한다.

왜 운영체제에 따라서 프로그램을 달리 구현해야 할까?

개발 언어가 다르기 때문이 아니라, 언어가 동일할지라도 운영체제에 따라서 프로그램을 완성하는 방식 자체가 다른 일부 기능이 존재하기 때문이다.

예를 들어서 그래픽, 키보드, 마우스 같은 하드웨어 IO 관련 기능들은 운영체제에 의해 제공되기 때문에, 운영체제가 달라지면 개발 언어와 상관없이 기능의 완성방법이 달라진다.
즉 하나의 프로그램이 서로 다른 운영체제에서 동작하는 것은 거의 불가능한 일이다.

다시 돌아와서 자바로 프로그램을 구현하면 운영체제에 상관없이 프로그램을 동작시킬 수 있는 장점이 있다. 운영체제에 따른 차이점을 바로 JVM이 대신 처리해주기 때문이다.

위 그림을 보면 운영체제 별로 존재하는 차이점을 JVM에서 다 처리하였기 때문에 자바 프로그램은 운영체제와 독립적으로 실행이 된다.

하지만 아까 말했듯이 JVM은 운영체제 위에서 동작하는 소프트웨어기 때문에 운영체제에 의존적이여서 Windows에는 Windows의 JVM이 필요하고, Mac에는 Mac에서의 JVM이 필요하게 된다.

💡 컴파일 하는 과정

위에서 살펴 보았듯이 자바는 OS에 독립적이라는 특징을 가지고 있다. 그리고 그게 가능한 이유는 자바 프로그램과 OS사이에 존재하고 있는 JVM 덕분이라는 것도 알게되었다.

그렇다면 JVM의 어떠한 기능 때문에, OS에 독립적으로 실행시킬 수 있는지 자바 컴파일 과정을 통해 알아보도록 하자.

1. 개발자가 자바 소스파일(.java)를 작성한다.

2. 자바 컴파일러(Java Compiler)가 자바 소스파일을 컴파일한다.
   컴파일러가 컴파일을 완료하면 자바 바이트 코드(.class)파일이 생성된다. 이 파일은 JVM만 읽을 수 있으며 아직 OS까지는 읽을 수 없는 이다.

3. 바이트 코드가 JVM의 클래스 로더(Class Loader)에게 전달된다. 클래스 로더에 전달되는 순간부터 런타임 환경에 접어든다.

4. 클래스 로더에서는 동적 로딩을 통해 필요한 클래스들을 로딩하여 JVM 메모리에 올린다. JVM 메모리는 런타임 데이터 영역(Runtime Data Area)이라고 한다.

5. 실행엔진(Execution Engine)에서 JVM 메모리에 올라온 바이트 코드들을 명령어 단위로 하나씩 가져와서 실행한다.
   이때, 실행 엔진은 두가지 방식이 있다.

• 자바 인터프리터 : 바이트 코드 명령어를 하나씩 읽어서 해석하고 실행한다. 하나하나의 실행은 빠르나, 전체적인 실행 속도가 느리다는 단점이 있다.

• JIT 컴파일러(Just-In-Time Compiler) : 바이트 코드 전체를 컴파일하여 바이너리 코드로 변경하고 이후에는 해당 메서드를 더 이상 인터프리팅 하지 않고, 바이너리 코드로 직접 실행하는 컴파일러이다.
  인터프리터의 단점을 보완하기 위해 도입된 방식으로, 하나씩 인터프리팅하여 실행하는 것이 아니라 바이트 코드 전체가 컴파일된 바이너리 코드를 실행하는 것이기 때문에 전체적인 실행속도는 인터프리팅 방식보다 빠르다.

클래스 로더내에서의 세부 동작

a. 로드 : 컴파일된 바이트 코드와 필요한 자바 클래스 라이브러리 파일을 가져와서 JVM의 메모리에 로드한다.

b. 검증 : 메모리에 로드된 파일이 자바 언어 명세(Java Language Specification) 및 JVM 명세에 명시된 대로 구성되어 있는지 검사한다.

c. 준비 : 클래스가 필요로 하는 메모리를 할당한다. (필드, 메서드, 인터페이스 등등)

d. 분석 : 클래스의 상수 풀 내 모든 심볼릭 레퍼런스를 다이렉트 레퍼런스로 변경한다.

기본 자료형(primitive data type)을 제외한 모든 타입(클래스와 인터페이스)을 명시적인 메모리 주소 기반의 레퍼런스가 아니라, 실행 시 Link를 할 수 있는 심볼릭 레퍼런스를 통해 참조한다.

심볼릭 레퍼런스는 메모리 번지의 참조를 의미하는 것이 아니라 이름에 의한 참조를 의미한다.

이 심볼릭 레퍼런스가 앞의 로드 - 검증 - 준비 과정을 거치고 실제 물리적인 주소인 다이렉트 레퍼런스로 대체되는 작업인 다이나믹 Linking이 이 단계에서 일어난다.

b.~ d.까지를 묶어서 연결이라고도 한다.

e. 초기화 : 클래스 변수들을 적절한 값으로 초기화한다.(static 필드)

💡 컴파일 및 실행하는 방법

Test.java

class Hello{

    public static void main(String[] args){
        System.out.println("Hello Java!");
    }

}

위와 같은 자바 소스파일이 있을 때, 자바 소스파일을 컴파일 하는 방법은 아래와 같다.

$ javac Test.java

javac(java compile or java compiler) 명령어로 자바 컴파일러가 자바 파일을 컴파일한다.

성공적으로 컴파일을 마친다면, 해당 경로에 Hello.class 파일이 생성된다.

컴파일 결과로 생성된 Hello.class 파일이 바로 자바 바이트 코드이다.

자바 바이트 코드를 실행시켜야 우리가 원하는 출력을 확인할 수 있다.

$ java Hello

> Hello Java!

위 java 명령어로 자바 바이트 코드파일을 자바 인터프리터가 해석하고 실행한다.

여기서 주목할 점은 Test.java 파일을 컴파일한 결과는 Test.class가 아니다.

Test는 포장지 이름이고 포장 속 알멩이는 Hello 클래스이다.

컴파일 결과 생성된 파일은 Class 이름의 Hello.class 파일이 생성된다.

💡 바이트코드란 무엇인가

자바 바이트 코드(Java bytecode)란 바이트코드 컴파일러가 자바 소스코드를 중간 언어인 바이트 코드로 변환한 것이다.

바이트 코드가 기계어는 아니지만 JVM에 의해 손쉽게 기계어로 변환될 수 있는 코드이다.

바이트 코드라고 불리는 이유는, 자바 컴파일러에 의해 변환되는 코드의 명령어 크기가 1바이트라서 자바 바이트 코드라고 불리고 있다.

자바 바이트 코드의 확장자는 .class이고, 자바가 OS에 독립적이므로 자바 바이트 코드는 JVM만 설치되어 있으면 어떤 OS에서라도 실행될 수 있다.

outer:
for (int i = 2; i < 1000; i++) {
    for (int j = 2; j < i; j++) {
        if (i % j == 0)
            continue outer;
    }
    System.out.println (i);
}

위 자바 코드를 자바 컴파일러가 컴파일을 하면 아래와 같은 자바 바이트 코드가 생성이 된다고 한다.

0:   iconst_2
1:   istore_1
2:   iload_1
3:   sipush  1000
6:   if_icmpge       44
9:   iconst_2
10:  istore_2
11:  iload_2
12:  iload_1
13:  if_icmpge       31
16:  iload_1
17:  iload_2
18:  irem
19:  ifne    25
22:  goto    38
25:  iinc    2, 1
28:  goto    11
31:  getstatic       #84; // Field java/lang/System.out:Ljava/io/PrintStream;
34:  iload_1
35:  invokevirtual   #85; // Method java/io/PrintStream.println:(I)V
38:  iinc    1, 1
41:  goto    2
44:  return

자바 프로그래머가 자바 바이트 코드를 반드시 이해해야 한다고 말 할 수 없다고는 하지만, 파이썬 프로그래머가 C에 대한 이해가 필요하고

C나 C++ 프로그래머가 어셈블리어를 이해하는 것과 비슷하게 개발을 하다 보면 때로는 해당 레벨보다 좀 더 로우 레벨에 대한 이해가 필요할 때가 있다.

자바 프로그래머 또한 바이트코드를 이해하고 자바 컴파일러에 의해 바이트코드가 어떻게 생성될 것인지를 이해하는 것이 필요하단 생각이 든다.

💡 JIT 컴파일러란 무엇이며 어떻게 동작하는지

위에서도 살짝 보았듯이 JIT 컴파일러란 바이트 코드 전체를 컴파일하여 바이너리 코드로 변경하고 이후에는 해당 메서드를 더 이상 인터프리팅 하지 않고, 바이너리 코드로 직접 실행하여 빠른 속도로 기계어를 생성할 수 있는 컴파일 기법이다.

JIT은 ‘실시간’ 비스무스한 뜻을 내포한 Just — In — Time의 약어인데, 왜 이러한 이름이 붙혀졌냐면 속도가 느린 인터프리터의 단점을 보완하기 위해 도입된 방식으로 JIT 컴파일러는 프로그램을 실제 실행하는 시점에(실시간에) 기계어로 번역하여 전체적인 실행속도는 인터프리팅 방식보다 빠르기 때문이다.

또한 기계어로 변환된 코드는 캐시에 저장되기 때문에 재사용시 컴파일을 다시 할 필요가 없다.

JIT 코드는 일반적인 인터프러터 언어에 비해 훨씬 좋은 성능을 낸다. 심지어 경우에 따라 정적 컴파일러 언어보다 좋은 성능을 내곤 하는데, 이는 실행 과정에 컴파일을 할 수 있기 때문에 가지는 장점이라고 할 수 있다.

💡 JVM 구성 요소

JVM 은 크게 4가지(Class Loader, Execution Engine, Garbage Collector, Runtime Data Area)로 나누어 진다.

1. Class Loader

자바 컴파일러에 의해 바이트코드로 변환된 클래스를 읽어들여 Runtime Data Area 에 적재하는 역할을 한다.

2. Execution Engine

Class Loader 에 의해 Runtime Data Area 에 적재된 바이트 코드를 명령어 단위로 하나씩 가져와 기계어로 변환하고 실행하는 역할을 한다.

앞서 보았듯이, 실행 엔진에는 Interpreter 방식과, JIT 컴파일러 방식을 사용한다.

JIT으로 중복되는 부분을 미리 체크해두고 라인별로 인터프리터 방식으로 실행한다고 한다. 그리고 체크한 부분에 도달하면 미리 캐시 저장된 값을 실행하는 방식을 채택하고 있다.

3. Runtime Data Area

JVM 의 메모리 영역으로 자바 애플리케이션을 실행할 때 사용되는 데이터들을 적재하는 영역이다.

이 메모리 영역은 다시 5가지 영역으로 구분할 수 있다.

a. Class Area or Method Area

클래스 정보가 저장되는 공간이다.

클래스의 멤버 변수의 이름과 타입, 메소드의 이름과 파라미터 그리고 리턴값과 같은 정보가 저장되고, 각종 상수, static 메소드, final 클래스 변수 등이 저장된다.

b. Heap Area

Heap Area에는 new 키워드에 의해 생성되는 클래스와 배열 등이 저장된다.

Method Area 영역에 저장된 클래스만이 생성 가능하고, Garbage Collector 에 의해 사용되지 않는 클래스/배열이 제거된다.

Garbage Collector는 아래에서 좀 더 자세히 다루도록 하겠다.

c. Stack Area

Stack Area는 지역 변수, 파라미터, 리턴 값, 연산에 사용되는 임시 값등이 생성되는 영역이다.

예를 들어, Person p = new Person(); 와 같이 클래스를 생성할 경우, new 에 의해 생성된 클래스는 Heap Area 에 저장되고, Stack Area 에는 생성된 클래스의 참조인 p 만 저장된다.

그리고 클래스의 메소드를 실행할 때마다 스택이 생성되며, Method Area, Heap Area 를 제외한 영역들은 스레드간에 공유되지 않는다.

d. PC Register

PC Register는 스레드가 생성될 때마다 생성되며, 현재 실행중인 주소와 명령을 저장한다.

멀티 스레드가 동작할 때, 이곳의 정보를 이용해 여러 스레드를 동시에 실행할 수 있다.

e. Native Method Stack

Native Method Stack에는 자바 이외의 코드가 저장되는 공간이다.

4. Garbage Collector (GC)

위에서 Heap Area에서 Garbage Collector 가 등장했었는데, GC는 Heap 영역에 생성되어 있는 객체들 중 참조되지 않는 객체를 찾아 제거하는 역할을 한다.

GC를 이해하면 왜 자바 객체가 주소값을 사용하지 않고, 참조값을 사용하는지 알 수 있다.

GC 과정을 좀 러프하게 설명하자면,

1 Eden이 꽉차면 참조되는 애들을 Survivor1에 옮긴다.

2. Eden을 싹 민다.

3. 나중에 Survivor1가 꽉차면 참조되는 애들을 Survivor2에 옮긴다.

4. Survivor1을 싹 민다. (1 또는 2 중 한군데는 비어있어야 함.)

5. 위 과정이 반복됨에도 계속 살아남은 애들은 Old 즉, Major GC로 옮긴다.

위 과정처럼 GC에 의해 참조되는 애들이 이동하게되면 JVM Obj(Address Mapping) Table 에서 실제 address는 oxaaaa에서 oxbbbb로 변경된다.

하지만 ref는 그대로이기 때문에 자바 객체가 address를 사용하지 않고, ref를 사용한다.

이러한 연유로 GC를 이해하면 왜 자바 객체가 주소값을 사용하지 않고, 참조값을 사용하는지 알 수 있다고 하는 것이다.

💡 JDK와 JRE의 차이

위 이미지로 JRE(Java Runtime Environment)와 JDK(Java Development Kit)는 간단하게 설명이 가능하다.

JRE(Java Runtime Environment) 는 자바 실행 환경의 줄임말로 JVM + 자바 API 등 자바를 실행하기 위한 프로그램 이다.

실제 자바를 설치하려면 JVM만을 설치할수는 없고 JRE를 설치하게 된다.

마인크래프트 같은 자바로 만들어진 프로그램의 실행을 위해 설치를 요구하는 경우 JRE를 깔게된다.

보통 일반 사용자용 JAVA라고 하면 이 JRE를 말한다.

JDK(Java Development Kit) 는 자바 개발 키트의 줄임말로 JRE + 컴파일러, 디버거 등 개발도구를을 포함하는 프로그램 이다.

JDK는 폐쇄적 상업코드 기반의 오라클JDK와 오픈소스인 OpenJDK가 있다.

OpenJDK는 오라클, Azul 등에서 제공하고 있으며,

이 OpenJDK를 기반으로 반들어진 자체개발JDK를 포함한 제품들도 많이 있다.