목차
JVM?
JVM 내부 구조
Bytecode 예제 실행
태초에 문제가 있었다.
C/C++는 컴파일 플랫폼과 타겟 플랫폼이 다를 경우, 프로그램이 동작하지 않는다.
*환경 플랫폼 = 운영체제 + CPU 아키텍쳐
물론 개발할 때는 문제없다. 동일한 플랫폼에서 컴파일과 실행을 같이 한다면, 프로그램은 아무 문제없이 동작한다.
배포할 때 문제가 발생한다. 플랫폼이 달라질 경우 프로그램으로 동작하지 않는다.
크로스 컴파일(Cross Complie)
타겟 플랫폼에 맞춰 컴파일하는 것을 '크로스 컴파일'이라 한다.
JVM으로 문제를 해결
자바 바이트코드는 타겟 플랫폼에 상관없이 JVM 위에서 동작한다.
WORA(Write Once, Run Anywhere) : 네가 짠 자바 코드를 컴파일해서 배포하면, 어떤 플랫폼이든 다시 컴파일할 필요 없이 실행시킬 수 있어! 근데 실행하려면 그 플랫폼에 맞는 JVM이 설치되어 있어야 해 (Sun Microsystems)
굳이 JVM?
C/C++도 크로스 컴파일해서 배포하면 되는데, 굳이 JVM을 사용해야하나?
본래 자바는 네트워크에 연결된 모든 디바이스에서 작동하는 것이 목적이었다.
디바이스나마다 운영체제나 하드웨어가 다르기 떄문에, 자연스럽게 플랫폼에 의존하지 않도록 언어를 설계했다. 그 결과가 Java Bytecode, JVM.
자바 코드가 실행되기까지
컴파일러에도 프론트엔드와 백엔드가 존재한다. 프론트엔드는 거의 바뀌지 않고 백엔드가 다르다.
런타임에서 발생하는 오류들의 정보들을 가지고 최적화를 하는게 JIT Complier이다.
이후의 내용은 전공지식이 상당수 언급되므로 인지만 할 것. 또한 본 포스팅에 분류된 소제목 외에 다양한 분야가 언급된다.
Runtime Data Areas
Method Area
Stack Frame
스택 프레임은 메서드가 호출될 때마다 새로 생겨 스택에 push 된다. 스택 프레임은 Local variables array, Operand stack, Frame Data를 갖는다. Frame Data는 Constant Pool, 이전 스택 프레임에 대한 정보, 현재 메서드가 속한 클래스/객체에 대한 참조 등의 정보를 갖는다.
Bytecode Example
보통 피연산자를 저장하는데 레지스터를 쓰는데, JAVA는 Stack을 쓰는 것 을 선택한다. 그 이유는?
JAVA의 야심. 다기종 인터페이스에서 작동할 수 있게 만드는 것. 기종마다 레지스터의 차이가 존재한다.
Stack을 쓰면 계산과정은 복잡하더라도 실제 하드웨어 스펙에 최소한의 관여를 함. 원활한 추상화를 위함. 코드가 간결해서 네트워크로 전송하기에도 용이함.
Ref.)
Java Virtual Machine Specifications. 2nd edition - Lindhom et. al.
-> JVM이 어떤 기능을 제공해야 된다는 명세를 나타낸 것.
Inside Java Virtual Machine - Bill Venners.
-> JVM의 구현에서 어떤선택을 했고 구현방법에 서술한 책.
