무민의 JVM Stack & Heap를 보고 정리한 내용입니다.
📌 C/C++와 JVM의 비교
✅ C/C++
- 컴파일 타임에 플랫폼에 종속
- OS, CPU 아키텍처에 따라 바이너리가 달라짐
- 배포 시 문제 발생
- Linux에서 컴파일한 실행 파일은 Windows에서 실행되지 않음
- 해결책: 크로스 컴파일(Cross Compile)
- 타겟 플랫폼을 명시하고 해당 환경에 맞는 실행 파일을 미리 컴파일
✅ Java (JVM 기반)
- 컴파일 결과: 바이트코드(.class)
→ 플랫폼 독립적인 중간 코드 - 실행: JVM 위에서 동작
→ JVM만 해당 플랫폼에 맞춰 설치되어 있으면 실행 가능 - 장점: WORA (Write Once, Run Anywhere)
→ 자바는 네트워크 환경과 다양한 디바이스를 고려해 설계됨
🧠 JVM Runtime Data Areas
JVM은 자바 바이트코드를 실행하기 위해 다양한 메모리 영역을 사용합니다.
📌 1. Method Area
- 클래스 구조 정보 저장 (클래스명, 상속, 필드, 메서드 등)
- JVM이
.class파일을 읽으면 이곳에 저장 - 모든 스레드에서 공유
📌 2. Heap
- 런타임 중 생성되는 모든 객체가 저장되는 공간
- new 연산자, 배열 등 객체 인스턴스 보관
- GC(Garbage Collector)가 관리
- 모든 스레드에서 공유
📌 3. Stack
- 스레드마다 독립적인 JVM Stack 존재
- 메서드 호출 시마다 Stack Frame이 생성되며, 종료 시 제거
🔹 Stack Frame 구성
| 구성 요소 | 설명 |
|---|---|
| Local Variable Array | 지역 변수 저장 (파라미터 포함) |
| Operand Stack | 연산 중간 결과 저장 |
| Frame Data | 예외 처리, 상위 호출 메서드 정보 등 |
📌 4. PC Register
- 현재 실행 중인 바이트코드의 주소를 저장
- JVM이 이 값을 보고 어떤 명령을 실행할지 판단
- 스레드마다 하나씩 존재
📌 5. Native Method Stack
- JNI(Java Native Interface) 기반 메서드 실행 시 사용
System.gc()등 C/C++로 구현된 native 메서드 실행 영역
✅ 보충 설명
🔧 왜 JVM인가?
C/C++도 크로스 컴파일이 가능하지만 JVM은 다음과 같은 이점이 있습니다:
- 보안성: 바이트코드 검증 → 위험한 코드 방지
- 성능 최적화: JIT(Just-In-Time) 컴파일러로 런타임에 최적화
- 메모리 관리 자동화: GC(Garbage Collector) 지원
✨ 마무리 요약
| 항목 | C/C++ | Java (JVM) |
|---|---|---|
| 컴파일 결과 | 바이너리 | 바이트코드(.class) |
| 실행 환경 | OS+CPU 직접 | JVM 위에서 실행 |
| 이식성 | 낮음 | 높음 |
| 메모리 | 명시적 관리 | GC 자동 관리 |
| 보안 | 낮음 (포인터 등 위험 존재) | 높음 (JVM 검증) |
