요번 포스팅에는 저번 포스팅에 이어 HotspotJVM의 Garbage Collector에 대해 알아보도록 하겠다. 

HotspotJVM의 Garbage Collector에는 5가지 종류의 Collector들이 존재한다. 

1.Serial Collector 

2.Parallel Collector

3.Parallel Compaction Collector 

4. CMS Collector 

5. Garbage First Collector 

제일 먼저 Serial Collector에 대해 알아보자. 

1.Serial Collector 

Young Generation과 Old Generation의 Garbage Collection  모두를  Serial로 처리하는 방식이다. 

1개의 Thread를 가지고 GC수행하고, Hotspot JVM의 가장 기본적인 collector이다. 

Young Generation – Generational Algorithm의 동작원리를 살펴볼까?

Minor GC가  발생 하면  

Minor GC가  발생결과 

old Generation – Mark and Compacting 알고리즘의 동작원리를 살펴볼까?

Serial Collector가 나온 이후 IT환경이 급변하여, heap의 크기를 점점 크게 설정해야 하는 상황이 도래함에 따라 Serial Collector의 한계가 드러나기 시작하였다.가장 큰 문제는 GC를 수행 하는 중에 나타나는 suspend현상인데 

heap이 커짐에 따라 suspend현상은 두드러졌고 application은 점점 실시간에 가까운 성능을 요구하고 있었다. 

그래서 두가지 전략으로 분화 되었다.

*Throughput Collector

모든 리소스를 투입하여 garbage collector를 빨리 끝내자는 전략.

이는 대용량의 heap에 적합하며,

이 전략을 채택한 garbage collector는 병렬 처리를 수행하는 방법으로 채택. 

*Low Pause Collector 

Suspend를 분산시켜 체감 pause time을 줄이자는 전략. 

실시간을 요구하는 application에 적합. 이 전략을 채택한 Garbage Collector는 GC를 수행하는

동시에 application의 작업도 수행(concurrent)하는 방식을 사용하고 있음.

2.Parallel Collector 

2014년 하고 싶은 일 중 하나가 전공 관련 스터디 해보기였다. 

그러던 중 한 개발자 커뮤니티에서 스터디원을 모집했는데  ‘JAVA 그리고 JVM’이라는 스터디를 선택했고,

6개월간의 스터디 기간 동안 배웠던 내용 중 하나가 바로 Garbage Collection이다.

그래서 오늘은 배운내용도 공유할겸 Garbage Collection에 대해 간단히 소개해 보는 시간을 갖도록 하겠다. 

1.Garbage Collection이란 ? 

“Heap storage for objects is reclaimed by an automatic

storage management system(typically a garbage collector);

objects are never explicitly deallocated.”

--Java Virtual Machine Speculation, Section 3.5.3[JVMS2 1999]

2.Garbage Collection의 대상

Garbage Collection은 Garbage를 모으는 작업이다.

그럼 Garbage를 정의하고 넘어가면, Heap과 Method Area에서 사용되지 않는 Object를 의미하는데,

사용되지 않는 다는 의미를 어디까지 볼 것이냐는 문제가 있다.

현재 사용 여부는 Root Set과의 관계로 판단하는데  

Root Set에서 어떤 식으로든 Reference관계가 있다면 Reachable Object.

즉 현재 사용하고 있는 Object로 간주하고 이렇게 판단해서 Reachable Object가 아니면 Garbage

Collection의 대상이 된다.

*여기서 Root Set이란 

한 객체는 여러 다른 객체를 참조하고, 참조된 다른 객체들도 마찬가지로 또 다른 객체들을 참조할 수 있

으므로 객체들은 참조 사슬을 이룬다. 이런 상황에서 유효한 참조 여부를 파악하려면 항상 유효한 최초

의 참조가 있어야 하는데 이를 객체 참조의 root set이라고 한다.

3.Garbage Collection과 단편화 문제

새로운 Object의 할당을 위해 한정된 Heap공간을 재활용하려는 목적으로 수행한다.

재활용을 위해 수행된 메모리의 해지는 할당한 그 자리에서 이루어지기 때문에 Garbage가 빠져 나간자

리는 듬성듬성 해지는데 Heap의 단편화(Fragmentation)발생한다.  

이러한 현상을 방지하기 위해 Compaction과 같은 Algorithm을 사용한다. 

다시한번 정리하면 Garbage Collection이란 

Heap을 재활용하기 위해 Root Set에서 참조되지 않는 Object를 없애 

가용한 공간을 만드는 작업을 말한다.  

이제는 Hotspot JVM의 Garbage Collection 소개해볼까 한다. 

Garbage Collector는 두 가지 가설 하에 만들어지는데 아래와 같다. 

--대부분의 객체는 금방 접근 불가능 상태가 된다. – high infant mortality

--오래된 객체에서 젊은 객체로의 참조는 아주 적게 존재한다.

이러한 가설을 ‘weak generational Hypothesis’이라 하고 

이러한 가설의 장점을 최대한 살리기 위해 Hotspot JVM에서는 크게 2개로 물리적 공간을 나누었다. 

Young 영역(Yong Generation 영역):

새롭게 생성한 객체의 대부분이 여기에 위치.대부분의 객체가 금방 접근 불가능 상태가 되기 때문에 매우 많

은 객체가 Young 영역에 생성되었다가 사라짐.이 영역에서 객체가 사라질때 Minor GC가 발생한다고 말함.

Old 영역(Old Generation 영역): 

접근 불가능 상태로 되지 않아 Young 영역에서 살아남은 객체가 여기로 복사됨. 대부분 Young 영역보다 크

게 할당하며, 크기가 큰 만큼 Young 영역보다 GC는 적게 발생. 이 영역에서 객체가 사라질 때 Major GC(혹

은 Full GC)가 발생한다고 말함.

*여기서 잠깐 

Old 영역에 있는 객체가 Young 영역의 객체를 참조하는 경우가 있을 때에는 어떻게 처리될까?

Card Table이라는 장치를 마련했는데  

Card Table 이란 Old Generation의 메모리를 대표하는 별도의 메모리 구조를 의미한다. 

만약  Young Object를 참조한 Old Object가 있다면 그 Old Object 시작주소에 해당하는 카드를 Dirty로 

표시하고, 만약 이 Reference가 해제되면 Dirty 표시가 사라진다.

Card Table에 Card들을 늘어 놓고 뒤집어 가며 Reference의 존재 여부를 한 눈에 파악할 수 있게 해준다.

여기까지 정리하고,

다음시간에는 Hotspot JVM의 Garbage Collector에 대해 알아보도록 하겠다. 

참조문헌:

•http://blog.takipi.com/garbage-collectors-serial-vs-parallel-vs-cms-vs-the-g1-and-whats-new-in-java-8/

•http://www.omsn.de/blog/brief-comparison-of-java-7-hotspot-garbage-collectors

•Java Performance Fundamental 김한도 지음 ㈜엑셈

•http://helloworld.naver.com/helloworld/textyle/1329

•http://blog.jelastic.com/2013/01/24/the-truth-about-paas-vertical-scaling-and-why-you-are-being-oversold/

•https://www.google.co.kr/urlsa=t&rct=j&q=&esrc=s&source=web&cd=1&sqi=2&ved=0CCUQFjAA&url=http%3A%2F%2Fwww.oracle.com%2Ftechnetwork%2Fjava%2Fjavase%2Ftech%2Findex-jsp-140228.html&ei=MMXaVL2TJOe5mwWZnoCADw&usg=AFQjCNHhFj3D5-BfVBPuZ6JL7JF7PCX-UA&sig2=z4gqAR4bu7LA-7IN2lLwbg&bvm=bv.85761416,d.dGc&cad=rja

•http://www.infoq.com/articles/Java_Garbage_Collection_Distilled

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(김한도 저)

2014년 11월 22일 2014 공개 소프트웨어 <실시간 데이터분석 오픈소스 프로젝트>에 참가하게 되었습니다. 

총 5가지의 세션으로 이루어졌고 세미나는 오후 1시에서 6시까지 진행되었습니다. 

저는 5가지 세션중 1가지 세션이 기억에 많이 남았는데요. 

그건 바로 실시간스트리밍 데이터분석을 위한 인프라운영입니다.

실시간으로 데이터를 분석 하는 것은 부담이 많이 되는 작업입니다.  그래서 이러한 작업을 하면서 목표로 하는 것은 어떠한 트래픽에도 문제 없이 돌아갈 수 있도록 하는 것인데요. 

발표자 안명호씨는 이러한 목표를 이루기 위해서는 아래의 3가지가 필요하다고 하셨습니다.

1. Dynamic 

2. More Management 

3. Scalability

그리고 이러한 목적을 이루는데 도움이 되는 것으로  클라우드가 많이 언급되었습니다. 

첫번째. Dynamic 

물리적인 서버에서는 불가능 하지만 클라우드에서는 가상 서버, 가상 네트워크, 가상 스토리지를 동적(Dynamic)으로 생성 소멸이 가능하다는 점 입니다. 

이러한 점을 잘 활용한 곳이 Netflix라는 기업이라고 합니다.

이에 관해서 구글신에 검색해 보니 아래와 같은 글이 있어 링크 첨부합니다 ^^

Why Netflix is one of the most important cloud computing companies

두번째. Management

물리적인 구성에서는 하나하나 관리하기가 힘들지만 클라우드에서는 가상 인프라로 통합관리(Management)가 가능하다는 점입니다.

세번째. Scalability

발표자는 Scalability라는 것을 집고 넘어갔는데, 

Scalability라는 것은 클라우드에서 얼마나 많은 인스턴스들이 돌아가느냐가 아니라 얼마나 많은 인스턴스들을 클라우드에서 동시에 생성할수 있느냐가 맞으며,  얼마나 많은 노드를 가지고 있느냐가 아니라 많은 노드를 생성하는데 얼마나 걸리냐가 맞는 것이라고 했습니다. 

위에 세가지를 말했는데, 간단하게 말하면 클라우드를 통해 Automation를 실현시킬수 있다고 합니다.

소프트웨어기반은 표준화가 가능하고 결국 표준에 맞게 작성할수 있는데,  사용자가 템플릿을 작성하면 동적으로 만들어 Resource Management가 가능하고,  사람이 하지 않고, 자동화 도구(즉, 소프트웨어)를 통해서 Configuration Management를 실현할 수 있다고 합니다. 

발표를 들으면서 100% 완전히 이해 된 것은 아니지만 이를 통해 민기부장님이 내주신 숙제가 생각 났었는데요. 

아래와 같습니다. 

투표를 한 유저정보를 최대 5초내로 다른 시스템에 http call하게 해달라.

B 업체에선 http call해서 받은 데이터를 디비에 저장한다.

회사에서 어떠한 것이든 지원해준다 생각하고 설계를 해 보아라.

제가 생각해낸 방법은 아래 링크에 기록되어 있습니다. 

https://docs.google.com/document/d/1pGt4cRLB2UHsVXr1bKMY-EzowDyADmRe3MPBALbIog0/edit?usp=sharing

결론(물론 정답은 아니지만 ^^;)을 도출하기까지 과정이 적힌 간단한 스케치지만 이 발표를 들으면서 제가 내린 결론에서 확장해서(Azure같은 것을 생각해보며 ^^;) 생각해보는 계기가 되었습니다. 

그외 나머지 5가지 세션들은 BigStorage,Fastcatsearch 등등 제품 설명으로 이루어지는 시간이었습니다.

발표자료 하나가 slideshare에 공유되어 있길래 첨부해 놓았습니다.^^

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