[10분 테코톡] 🎅무민의 JVM Stack & Heap

출처 : https://www.youtube.com/watch?v=UzaGOXKVhwU

출처: https://lilys.ai/digest/7250866/7790564/

만약 자바(Java)가 없었다면 우리는 '이식성 지옥'에 갇혀 컴퓨터 종류마다 프로그램을 다시 만들어야 했을 겁니다. JVM(자바 가상 머신)은 운영체제나 CPU 종류와 상관없이 자바 코드가 어디서든 작동하게 만드는 마법의 통역사이자 실행 환경입니다 . 특히 JVM 내부의 스택(Stack)과 힙(Heap)은 이 프로그램을 돌리는 데 필요한 메모리 저장 공간인데, 스택은 임시 작업 공간처럼 쓰레드마다 개별적으로 존재하며 실행 중인 메소드 정보를 관리하고, 힙은 모든 객체들이 공유하는 영구적인 창고 역할을 합니다 .

1. JVM, 왜 필요한가요? 플랫폼 독립성이라는 마법

• C나 C++ 같은 언어는 프로그램을 만들 때부터 특정 컴퓨터(플랫폼)에 맞춰 컴파일해야 하는 까다로움이 있습니다 .
  • 예를 들어, 리눅스에서 만든 실행 파일을 윈도우에서 돌리면 절대 작동하지 않죠 .
  • 이 문제를 해결하려면 윈도우를 타겟으로 다시 컴파일해야 하는데, 이걸 크로스 컴파일(Cross-compile)이라고 합니다 .
• JVM은 이 문제를 근본적으로 해결했는데, 자바 소스 코드를 자바 컴파일러(javac)가 자바 바이트 코드(Byte Code)라는 중간 언어로 바꾸기 때문입니다 .
• 이 바이트 코드는 특정 OS나 CPU에 종속되지 않고, JVM만 설치되어 있다면 어떤 환경에서든 실행될 수 있는 공통어 역할을 합니다 .

2. 컴파일러의 역할: 프론트엔드와 백엔드의 분리

• 일반적인 컴파일러는 소스 코드를 분석하고(프론트엔드), 그것을 실제 기계어로 바꾸는 일(백엔드)을 모두 담당합니다 .
  • 프론트엔드는 소스 코드의 의미를 파악하는 부분이라 플랫폼이 바뀌어도 크게 달라지지 않아요 .
  • 하지만 백엔드는 운영체제나 기계어에 의존적이기 때문에 윈도우용, 리눅스용 등 종류별로 달라져야 합니다 .
• 자바는 이 역할을 분리했는데, JavaC(자바 컴파일러)가 프론트엔드 역할을 맡아 자바 바이트 코드를 만들고 .
  • JVM(자바 가상 머신)이 백엔드 역할을 맡아서 이 바이트 코드를 각 플랫폼에 맞게 실행해주는 겁니다 .

3. JVM의 내부 구조: 메모리 구획 나누기

• JVM은 자바 바이트 코드를 실행하기 위해 여러 종류의 메모리 공간을 사용하며, 크게 모든 쓰레드가 공유하는 영역과 쓰레드별로 독립적인 영역으로 나뉩니다 .

• 메소드 영역은 클래스 파일이 로드될 때 클래스의 구조 정보(변수, 메소드 정의 등)를 파싱해서 저장하는 곳입니다 .
• 힙은 우리가 new 키워드로 생성하는 모든 인스턴스(객체)들이 모여 사는 거대한 아파트 단지라고 생각하면 됩니다 .

4. 쓰레드별 작업 공간: 스택과 스택 프레임

• 프로그램에서 어떤 작업을 실행하는 단위인 쓰레드(Thread)는 각각 독립적인 메모리 공간을 가지고 있습니다 .
• 자바 스택 (Java Stack)은 쓰레드별로 하나씩 존재하며, 메소드를 호출할 때마다 새로운 스택 프레임(Stack Frame)이 생겨납니다 .
  • 스택은 마치 접시 쌓기처럼 위로 쌓이고(성장하고), 메소드 실행이 끝나면 가장 위에 있는 프레임(접시)부터 사라집니다 .
• 스택 프레임은 해당 메소드 실행에 필요한 모든 정보를 담고 있는 임시 박스입니다 .

5. 스택 프레임 속의 작업 도구: 로컬 변수와 오퍼랜드 스택

• 하나의 스택 프레임 안에는 해당 메소드가 돌아가는 데 필요한 중요한 세 가지 정보가 들어있습니다 .
• 로컬 변수 배열 (Local Variable Array): 우리가 메소드 안에서 선언한 변수들(예: int a = 10;)이 저장되는 공간입니다 .
  • 바이트 코드가 "로컬 변수 1번 인덱스에 저장해!"라고 명령하면 이 배열의 특정 위치에 값이 들어갑니다 .
• 오퍼랜드 스택 (Operand Stack): 실제 연산을 위한 임시 저장소로, CPU의 레지스터처럼 사용됩니다 .
  • 예를 들어, 두 숫자를 더하려면 바이트 코드 명령(dadd)을 통해 이 스택에서 두 값을 꺼내서 연산하고, 그 결과를 다시 이 스택에 넣습니다 .

6. JVM이 레지스터 대신 스택을 쓰는 이유: 단순함과 이식성

• 일반적인 CPU는 레지스터라는 초고속 메모리를 이용해 연산을 처리합니다. 그런데 JVM은 왜 이 복잡한 스택 기반 구조를 선택했을까요?
• JVM이 스택을 사용하는 가장 큰 이유는 이식성(Portability)을 극대화하기 위해서입니다 .
  • 레지스터 기반 구조를 쓰려면, 프로그램이 실행되는 컴퓨터의 CPU 레지스터 개수나 구조를 미리 알고 있어야 코드를 짤 수 있습니다 .
  • 이는 자바가 목표로 했던 "어디서든 동작"하는 범용성과 정면으로 충돌합니다.
• 스택 기반 구조는 실제 하드웨어의 복잡한 구조를 숨기고, 데이터를 넣고 빼는(Push/Pop) 단순한 방식으로 연산을 추상화하기 때문에 .
  • JVM은 하드웨어의 차이에 최소한으로 관여하면서도 바이트 코드를 안정적으로 실행할 수 있게 됩니다 .