Embian Blog

Runtime Data Areas는 Process로서의 JVM이 프로그램을 수행하기 위해 OS로부터 할당 받는 메모리 영역이라고 정의 내릴수 있는데 각각의 목적에 따라 5개의 영역으로 나뉜다. 

1.PC Registers

2.Java Virtual Machine Stacks

3.Native Method Stacks

4.Method Area

5.Heap

이렇게 말이다. PC Registers와 Java Virtual Machine Stacks, Native Method Stacks 각 Thread 별로 생성이 되고, Method Area와 Heap은 모든 Thread에게 공유된다. 

요번 포스팅에서 위에 5개 영역중 PC Registers에 대해 알아보도록 하자.

프로그램의 실행은 CPU에서 명령어,즉 instruction을 수행하는 과정으로 이루어진다. CPU는 이러한 Instruction을 수행하는 동안 필요한 정보를 레지스터라고 하는 CPU내의 기억장치를 사용한다. 

1+2라는 연산을 수행하는 경우 이것을 최소단위로 쪼개보면 연산의 대상이 되는 1과 2도 있을 것이고 더하라는 연산도 있을 것이다. 연산을 하나씩 수행해 보면 먼저 1이라는 값을 받고 다시 2라는 값을 받은 후 이 두 숫자를 더한 결과값을 내는 과정으로 진행될 것이다. 그런데 1을 받고 2를 받을 때 먼저 받아 놓은 1이라는 상수는 2를 받는 행위를 할 동안 이 값들은 CPU에 잠시 기억된다. 

1과 2처럼 명령 실행에 사용되는 데이터를 Operand라고 하며, 더하라는 연산 명령과 같은 add Instruction도 존재한다. CPU는 이것도 미리 기억을 하고 있었어야 한다. 그리고 이 연산의 결과인 3이라는 Operand도 메모리로 전달하기 전에 CPU 어딘가에 잠시 머무르도록 해야 한다. 

이때 사용하는 CPU내의 기억장치를 레지스터라 한다. 

하지만 Runtime Data Area의 메모리 영역인 PC Register는 이것과는 다르다. Java는 Register-Base로 구동되는 방식이 아니라 Stack-Base로 작동한다. JVM은 CPU에 직접 Instruction을 수행하지 않고 Stack에서 Operand를 뽑아 내어 이를 별도의 메모리 공간에 저장하는 방식을 취하고 있는데 이것이 PC Register이다.

Java는 플랫폼에 독립적이기는 하나 OS나 CPU의 입장에서 보면 하나의 프로세스에 지나지 않기 때문에 머신의 리소스를 사용해야 하는 것이 당연하다. 그렇기 때문에 Java도 현재 작업하는 내용을 CPU에 Instruction으로 제공해야 했고 이를 위한 버퍼공간으로서 PC Register라는 메모리 영역을 생성한 것이다. 

PC Register는 각 Thread마다 하나씩 존재하며 Thread가 시작할 때 생성된다. 

만약 Thread가 Java Method를 수행하고 있으면 Java Virtual Machine Instruction의 주소를 가지고 있게 된다. 만약 C언어등으로 Native Method를 수행하고 있다면 PC Registers는 undefined 상태로 있게 된다.왜냐하면 앞으로 배울 Native Method Stack에서 따로 처리하기때문이다. 이 PC Register에 저장되는 Instruction의 주소는 Native Pointer일 수도 있고 Method Bytecode의 시작점 일 수도 있다. Native Method를 수행할 때는 JVM을 거치지 않고 바로 수행하게 된다. 어차피 Native Code는 Platform에 종속 될 수 밖에 없기 때문에 JVM을 경유할 필요가 없기 때문이다. 

이렇게 PC Register에 설명해 보았다. 

다음 포스팅은 Java Virtual Machine Stacks에 대해 설명하도록 하겠다.

참고 Java performance Fundamental(김한도 저)

저번 포스팅에서 아래의 4가지 기술중  The Java Programming Language,The Java Class File Format 에 대해 알아보았다. 

- The Java Programming Language

- The Java Class File Format

- The Java Application Interface

- The Java Virtual Machine(JVM)

오늘은 The Java Application Interface와 The Java Virtual Machine(JVM)에 대해 자세히 알아보자. 

The Java Application Interface

Java Application Interface,즉 Java API는 한마디로 Runtime Library의 집합이라고 할 수 있다. 앞서 Class파일을 수행하기 위해서는 JRE가 필요하다고 하였다. 이 JRE는 말 그대로 Java 실행 환경이다. 여기에는 Java Virtual Machine과 Java API,그리고 Native Method등이 포함되어 있다. 

Java API는 OS 시스템과 Java 프로그램의 사이를 이어주는 가교의 역할을 한다. Java API는 Native Method를 통해 OS자원과 연계되어 있고 다른 한 편으로는 Java프로그램과 맞닥뜨리고 있다. 그야말로 Interface의 역할을 하고 있는 셈이다. 

만약 java.io.InputStream 이라는 클래스를 사용하여 특정 파일시스템의 정보를 읽어 온다고 가정해 보자. 파일시스템은 Platform에 따라 동일한 것을 사용하지 않는다. FAT를 사용할 수도 있고 JFS를 사용할 수도 있다.

그러나 Java를 사용하는 한 파일 시스템의 특정 정보를 읽기 위해서 Platform에 대해 고민할 필요는 없다. 그저 java.io.InputStream를 사용하기만 파일시스템에서 원하는 정보를 가져올 수 있기 때문이다. 

Java에서는 Class파일 내에 있는 java.io.InputStream이 Symbolic Reference를 이용하여 Runtime시 해당 Instance에 접근하게 된다. 그러면 이 Instance에 대한 내용, 즉 실제 File에 대한 접근은 Native Method를 통해 OS에 명령을 전달하게 된다. 이후 OS는 실제 File IO를 일으키게 되고, 이 File IO의 결과는 다시 Native Method를 통해 Java API로 전달되는 과정을 거쳐 프로그램이 실행되는 것이다. 

The Java Virtual Machine(JVM)

흔히 JVM을 computer in computer라고도 하는데 Java의 4가지 구성요소 중 가장 핵심적인 것이다. 

Java Virtual Machine은 그 이름에 자신의 모든 특성을 담고 있다. 

'JVM이 무엇이냐?'라고 하는 질문이 들어온다면 이 질문의 답은 JVM은 하나의 개념,스펙에 지나지 않는 것이라고 밖에 대답할 수 없다.JVM은 그 누구도 자세한 설계도를 만들어 제공하지 않는다.단지 JVM은 이렇게 저렇게 해야 한다는 식의 정의만으로 존재할 뿐이다. 표준화된 정의가 나오면 각 JVM 벤더들은 이에 맞도록 자신들의 JVM을 구현한다. 이 뿐이다. 그렇기 때문에 지구상 어디에도 정통 JVM이라는 것은 없다. 이것이 JVM의 가장 중요한 특징이다. 

종합해 보면 JVM은 정의된 Specification을 구현한 하나의 독자적인 Runtime Instance라고 할 수 있다. 여기서 하나의 독자적인 Instance라는 것은 하나의 프로세스 형태로 구동한다는 점을 강조한 것이다. 

위에 그림은 JVM의 기본적인 Architecture를 도식화한 것이다. JVM은 Class Loader System을 통해 Class 파일들을 JVM으로 로딩한다. 로딩된 Class파일들은 Execution Engine을 통해 해석된다. 이렇게 해석된 프로그램은 Runtime Data Areas에 배치되어 실질적인 수행이 이루어지게 된다. 이러한 실행 과정 속에서 JVM은 필요에 따라 Thread Synchronization과 Garbage Collection 같은 관리작업을 수행하게 된다. 

다음 포스팅에는 Runtime Data Areas의 구조의 각각의 모듈에 대해 설명하고자 한다. 그때까지 see you soon!

참고

Java Perfomance Fundamental(김한도 저)

지난 포스팅에서 Java는 "Write Once, Run Everywhere"라는 하나의 철학(물론,JRE에 기반하기 때문에 꼭 그렇지만은 않다;;;)으로 시작되어 발전된 개념인데 이 철학을 실현하기 위해 Java는 아래와 같은 네 가지의 상호 연관된 기술을 엮어놓았다고 설명을 했다 

- The Java Programming Language

- The Java Class File Format

- The Java Application Interface

- The Java Virtual Machine(JVM)

오늘은 이 4가지 기술 중 The Java Programming Language와 The Java Class File Format 에 대해 자세히 설명하고자 한다. 

Java Programming Language

보통 Java라는 언어를 언급할 때 가장 자주 등장하는 것이 바로 객체지향이라는 단어이다. 그러나 프로그램 언어 측면에서 Java의 가장 큰 특징은 무엇보다 생산성의 극대화와 동적인 면에 있다고 생각한다. 

java에는 Multi-Threading,구조화된 에러 핸들링, Garbage Collection, Dynamic Linking,Dynamic Extension 등의 기술

들이 있지만 이 중에서 방점을 찍고 싶은 기술은 다름아닌  Dynamic Linking이다. Java의 Class파일은 엄밀히 말하면,저번 포스팅에서도 말했듯이 실행 가능한 형태로 변경된 것이 아닌 JVM이 읽을 수 있는 형태로 번역된 것으로 이해할 수 있다. 이것은 JVM위에서 다시 실행 가능한 형태로 변형된다. 실행을 위한 Linking작업은 그때 일어나게 된다. 

Class파일은 실행시 Link를 할 수 있도록 Symbolic Reference만을 가지고 있다. 이 Symbolic Reference는 Runtime시점에서 메모리상에서 실제로 존재하는 물리적인 주소로 대체되는 작업인 Linking이 일어나게 되는 것이다. 이러한 Link작업은 필요할 때 마라 동적으로 이루어지기 때문에 이를 가리켜 Dynamic Linking이라고 한다. 

이 Dynamic Linking이라는 기술 덕분에 Class파일의 크기를 작게 유지할 수 있다. 

이것은  Java의 철학을 구현한다는 의미로 확대 된다. Java는 플랫폼에 독립적이기 때문에 Compile된 파일만 있으면 그대로 수행이 가능하다. 또한 Network을 통해 객체를 전송하고, 배포하는데 있어 파일의 크기는 작을수록 유리하다는 것은 충분히 예상 가능한 것이다. 그렇기 때문에 Compact한 Class파일은 Java의 철학을 실현하는데 있어 필수적인 요소가 되고 있다. 

하지만 무엇보다 프로그램의 언어로서 Java가 지니고 있는 특징은 생산성을 극대화 한다는 데 있다. 

Java가 생산성을 가질 수 있게 된 것은 역시 Runtime Memory를 직접 핸들링 하지 않기 때문이다.Java사용자는 Runtime Memory를 핸들링 해서도 안되고, 또한 할 수 있는 방법도 전혀 없다는 의미이다.(물론 핸들링을 할 수 있지만 왠만하면 사용하지 말라고 한다 ;;)이를 위해 Java는 Garbage Collection과 같은 기술을 채용했고 이는 개발 및 운영에 소요되는 시간과 노력을 많이 단축시켜 주었다. 

Java Class file format

Java는 개발자가 작성한 프로그램을 Compiler를 통해 Class파일로 재생성되는 과정을 거치게 된다. 

이렇게 생성된 Class파일은 다음의 네 가지 특징을 가지게 된다. 

-Compact한 형태 

-Bytecode로의 변경

-Platform 독립적

-Network Byte Order의 사용 

Java의 철학을 가장 두드러지게 대변하는 것이 바로 이 Class File Format이다. Class 파일은 Bytecode를 Binary형태로 담아놓는 것이라 할 수 있다. 

Bytecode는 JVM이 읽을 수 있는 언어를 의미한다.  Bytecode는 Java의 철학을 실현하는 중요한 요소들 중 하나이다. Bytecode가 JVM을 위한 언어라는점, 모든 Code가 Bytecode의 Binary형태로 실체화된 Class라는 것으로 배포된다는 점은 Platform의 제약을 뛰어 넘을 수 있게 되었다는 것을 의미하기 때문이다.  JVM이 Unix에 설치되어 있건,Windows에 설치되어있건 상관없이 Bytecode는 동일하게 수행된다. 이것을 다르게 표현하면 'Platform 독립적이다'라고 하는 것이다. 

또한 Bytecode는 Source Code를 단순히 JVM의 언어로 번역해 놓은 것이기 때문에 Source Code와 비슷한 크기를 가지고 있다. Compiler를 통해 실행파일로 변경되는 과정에서 Library들을 포함하는 C++과 같은 언어에 비한다면 아주 작은 크기라 할수 있다.  Class파일에는 라이브러리를 포함하지 않고, 단지 Symbolic Reference만을 가지고 있는데 Symbolic Reference는 참조하고자 하는 대상의 이름만으로 참조관계를 구성하는 것을 의미한다.  Class파일이 JVM에 올라가게 되면 Symbolic Reference는 그 이름에 맞는 객체의 주소를 찾아서 연결하는 작업을 수행한다. 이러한 과정을 Dynamic Linking이라 하는데 이것덕분에 Class 파일은 Compact한 형태를 유지 할 수 있는 것이다. 

마지막으로 Java Class file format 는 Network Byte Order를 사용한다는 것이다. Network Byte Order는 서로 다른 계열의 CPU끼리 데이터를 전송 받을 때의 문제점을 해결하기 위해 정해진 일종의 약속이다. RISC계열의 CPU를 사용하는 Unix머신에서 Pentium CPU를 장착한 Windows로 데이터를 보내는 것을 가정하자. Byte Order를 고려하지 않고 보낸다면 서로의 데이터는 주소가 반대로 되어 있어 제대로 전송되지 않을 것이다. 그렇기 때문에 Network를 통해 데이터를 전송할 때는 통일된 방식을 따르기로 약속을 했는데 이것이 바로 Network Byte Order 이다. Nerwork Byte Order는 Big Endian을 사용하기로 약속이 되어 있다. 

Class File Format은 Network Byte Order를 사용하기 때문에 Big Endian 방식을 사용하게 된다. 

이렇게 2가지 기술에 대해 설명해 보았다.

다음 포스팅에는 The Java Application Interface, The Java Virtual Machine(JVM)에 대해 설명하도록하겠다. 

참고

Java Perfomance Fundamental(김한도 저)