Embian Blog

저번 포스팅에서 아래의 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(김한도 저) 

회사에 입사하기전 여러군데에서 면접을 보면서 간혹 java에 특징에 대해 말해보라는 질문을 받곤 했었다. 

그러면 나는 객체지향 프로그래밍 언어의 한 종류이며, 플랫폼에 독립적어서 어디서나 실행된다는 말을 내뱉곤 했다. 단순히 java기본서에서 외워서 대답하던 것이었는데 나는 그것을 단순히 외우기만 할 뿐 왜 플랫폼에 독립적인지 그 이유에 대해선 따로 생각하지 않고 있었다. 회사에 입사하고 난 후에도 말이다. 

개발자로서 일을 한지 8개월이 되가고 있는 지금, 내가 java를 이용해서 개발을 하고 있는데 나는 java에 대해서 얼마나 알고 있을까 이런 생각이 들었다. 그래서 한 개발자 커뮤니티에서 운영하는 java와 jvm을 주제로 하는 스터디에 참여하게 되었다. 스터디를 하면서 나 혼자 알고 있기엔 너무나 아까운 내용도 많고, 공부한 내용도 정리 할겸 포스팅을 하려고 한다. 

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가지의 기술들을 살펴보기전에 우리가 Java로 프로그램을 만들어 수행하는 과정에 대해 알아보자.

우리가 Java Source Code를 작성하면 java라는 확장자를 가진 파일로 만들어지게 된다.

Java Source파일은 단순히 코드만을 담고 있는 파일일 뿐, 이 자체로는 수행 불가능하므로 수행하도록 하기 위해서는 Class 파일의 형태로 변경해 주어야 한다. 이 작업을 Compile이라고 한다. 

Java에서 Compile은 보통 JDK에 내장되어 있는 'javac'라고 하는 Compiler를 이용하여 수행한다

. 

이 작업을 수행하면 Source File과 같은 이름이지만 class라는 확장자를 가지는 Binary파일이 생성된다. 

이 class라는 확장자를 가진 파일은 수행이 가능한 형태의 파일이다. exe파일처럼 수행할수 있는 형태가 아니라 단순히 수행 가능한 형태라는 말이다. 

이것을 수행하기위해서는 적어도 JRE(Java Runtime Environment)라는 것이 필요하다. 물론 JDK도 가능하다. 

이 프로그램을 수행하기 위해서는 ' java'라는 프로그램을 호출하여 우리가 생성한 Class파일을 인수로 제공하면 된다. 이때  'java'라고 하는 프로그램은 Java실행 환경에 Class파일을 가지고 들어가는 역할을 하게 된다. 이러한 수행과정을 좀 더 자세히 살펴 보면 다음과 같다. 'java'라고 하는 프로그램은 Java Virtual Machine을 하나의 프로세스로 올리는 작업과 함께 Class파일의 로딩도 수행한다. 

그 이후 Class파일을 분석하여 JRE내에 있는 Java Application Program Interface(Java API)와 더불어 프로그램을 수행하도록 하는 것이다. 

java라는 확장자를 가진 소스파일로 Class파일로 생성하는 시점을 Compile Time이라고 하고, 앞서 생성된 Class파일을 수행하는 시점을 RunTime이라고 한다. 

앞서 언급한 4가지 기술

- The Java Programming Language

- The Java Class File Format

- The Java Application Interface

- The Java Virtual Machine(JVM)

들이 아래의 그림에 모두 포함되어 있다. 

처음 프로그램을 작성할때는 Java Programing Language이고, 작성한 프로그램을 Compile하면 Java Class File Format으로 변경된다. 이를 수행하기 위해서는 Java Virtual Machine을 구동시며 Class파일을 로딩한다. 

JVM으로 로딩된 프로그램은 단독으로 수행되는 것이 아니라 Java Application Pragramming Interface와 동적으로 연결되어 실행되는 것이다.

다음포스팅에서는 각각의 4가지 기술들에 대해 자세히 알아보는 시간을 가지겠다.

그때까지 See you soon!

참고

Java Perfomance Fundamental(김한도 저) 

개발자의 관점에서 CEP(Complex Event Processing)를 설명한 슬라이드입니다.

'CEP는 어렵지 않습니다. 언제나 우리(개발자)가 해 오던 것들일 뿐입니다.'

2013.09.26

이주현 (lee@embian.com, leejuhyeon@gmail.com)

I. 서설

 Java VisualVM(이하 VisualVM이라 한다)는 실행 중인 java 프로세스의 상태를 모니터링할 수 있는 좋은 도구이다. 이는 Oracle JDK에 포함되어 있으며, JDK 설치위치의 bin 디렉토리에 jvisualvm이라는 이름으로 존재한다.

 VisualVM은 로컬(VisualVM이 작동되는 머신과 동일한 머신)에서 실행 중인 java 프로세스 뿐만 아니라, 원격(VisualVM이 작동되는 머신과 상이한 머신)에서 실행 중인 java 프로세스 역시 모니터링할 수 있다.

 원격 모니터링의 경우, jstatd*^[각주:1] 또는 JMX^[각주:2]를 이용하는 두가지 방식을 제공하는데, JMX를 이용하는 것이 더 간단하고, 기능도 많다.

 이 글에서는 JMX를 활용하여 원격호스트의 java 프로세스를 모니터링하는 방법을 설명하고자 한다.

II. 환경설명

 다음과 같이 원격호스트와 로컬호스트가 존재하고, 원격호스트에서 실행 중인 Test라는 java 프로그램의 상태를 로컬호스트에서 VisualVM을 통하여 모니터링하기로 한다.

III. 방법

1. 원격호스트에서 실행될 Test.class 프로그램을 다음과 같은 환경변수와 함께 실행시킨다.

여기서 jvm 파라미터들은 다음과 같다.

* 여기서 인증사용 여부 등을 true로 하게 되면, jre 측에 별도의 보안 설정 등을 필요로 한다. 내부망이고 별도의 보안 정책이 없는 경우라면, 인증사용을 하지 않아도 충분하다.

2. 로컬호스트에서 VisualVM을 실행한다.

그러면 아래와 같이 VisualVM이 실행된다.

3. Visual VM에서 remote 접속을 수행한다.

 화면의 Applications 탭에서 Remote를 클릭하면, "Add Remote Host"라는 팝업이 뜬다. 이 팝업의 "Host name"에 원격호스트의 주소를 적어주고, OK 버튼을 누른다. (여기서는 원격호스트의 주소는 192.168.0.53이라고 가정한다)

그러면, 원격호스트가 Remote 항목 밑에 표시된다.

해당 원격호스트 항목에서 마우스 오른쪽 버튼을 클릭해서 "Add JMX Connection"을 선택한다.

 새로 열린 팝업 메뉴의 "Connection" 란에 원격호스트의 IP와 Port 번호를 적어준다. (본 예제의 원격호스트에서  java 프로세스를 실행할 때 지정한 JMX 포트 번호는 3333)

 그러면, Applications 탭에 원격호스트의 java 프로세스가 등록된 것이 보일 것이다.

 이제 해당 원격 프로세스 표시를 더블클릭하자. 그러면 다음과 같이 해당 java 프로세스의 상태가 표시될 것이다.

4. 이제 원격 java 프로세스의 상태를 모니터링한다.

아래와 같이 "Overview", "Monitor", "Thread", "Sampler" 등의 탭을 통하여 원격호스트 상의 java 프로세스의 상태를 모니터링할 수 있다.

IV. 결론

 원격호스트의 java 프로세스 상태를 모니터링함에 있어 jstatd를 사용하는 방법은, 별도의 rmiregistry를 기동하여야 하는 등 약간 귀찮은 면이 있다.

 이에 비하여 JMX를 활용하여 모니터링 대상의 JVM에 직접 접속하는 방법은 별도의 감시 데몬(jstatd)를 필요로 하지 않으면서도, 오히려 jstatd를 사용할 경우보다 다양한 기능(예를 들어 Heap Dump 등)을 제공하는 장점이 있다.