JVM 메모리 구조

JVM의 메모리 구조

그러나 자바 프로그래밍에서는 스태틱, 스택, 힙영역에만 중점을 둔다.

스태틱 영역에는 클래스가 컴파일되어 올라간다. 스택영역에는 기본적으로 하나의 선입후출(FILO) 스택 구조를 가지는 영역이 준비되고, 이곳에서 기본 타입에 대한 연산과 메서드 블록 변수가 계산된다. 필요한 객체를 생성하여 사용하려면 객체를 위한 힙 영역이 필요하다. 힙의 한 부분에 존재하는 리터럴풀(literal pool)이라는 영역은 new 키워드를 사용하지 않는 문자열을 저장한다.

스태틱, 스택, 힙 영역의 차이점을 보자면, Car car = null; 이라 선언만 하고 프로그램 내에서 오랫동안 사용하지 않거나 메모리가 부족하면 Car클래스는 스태틱 영역에서 제거된다. 제거대상이 되면 JVM이 필요에 의해 제거한다. 클래스 제거는 가비지 컬렉션(Garbage Collection, GC : 쓰레기를 수집하고 정리)라고도 하며, 가비지 컬렉터가 이를 수행한다. 스태틱 영역은 블록 변수를 처리하므로 수명이 가장 짧다. 메서드가 끝나면 메서드 내의 블록 변수는 모두 제거된다.  객체는 생성된 다음 힙 영역의 멤버 필드를 보관한다. Car car1 = null; 하면 객체는 살아있으나. 레퍼런스는 잃게 된다. 이런 것이 가지비이며, 가비지 컬렉터가 판단하여 가비지를 제거한다.


* static 메서드는 static 필드를 사용하지만 멤버 필드는 사용할 수 없다. 그러나 멤버 메서드는 static 필드를 사용할 수 있다.

SVN (Software Version Control System) 버전 관리 시스템

SVN (Software Version Control System) 버전 관리 시스템

기본적으로 Server-Client구조

리소스를 관리하고 업무 프로세스를 진행하는 두가지 모델

1. Lock-Modify-Unlock 모델 

 : 한명의 사용자가 파일을 열어 작업하고 있다면, 다른 사용자들은 해당 파일을 수정/저장 할 수 없게 함으로써, 하나의 작업물을 동시에 둘 이상의 사용자가 수정-commit하는 것을 방지한다. 수정 또한 작성한 본인만이 가능.

2. Copy-Modify-Merge 모델 

 : 통합 중심 버전 관리 기법. 모든 사용자가 하나의 작업물을 동시에 편집 가능하다.

용어

1. Revision : 작업물에 대한 고유 번호.저장소에 등록 할 때마다 등록 시점에 대한 고유 번호를 지정.

2. check-out : repository에서 파일 복사본들을 꺼내어 작업본안에 집어넣는 것.

3. export : repository에 있는 파일들의 한 snapshot

4. commit : 변경한 것들을 repository에 다시 집어 넣는 것.

5. trunk : 개발의 주된 흐름 

6. branch : trunk에서 하나의 가지(branch)를 만들어 릴리즈를 준비하는 것..

7. Conflict : 동시에 같은 파일을 두 명 이상의 사용자가 수정하고 각각 커밋할 경우 해당 파일은 충돌이 일어나고, 충돌된 파일의 내용을 merge하거나, 두 파일중 하나를 최신으로 지정하여 충돌 상태를 해결해야 한다.

8. Merge : 작업 복사본과 저장소에 있는 파일의 내용이 다를 경우, 병합 작업을 통하여 두 파일의 내용을 합치게 된다. 

형상관리(Configuration Management , CM)

버전관리가 곧 형상관리인 것은 아니다. 버젼 관리는 형상 관리에 쓰이는 하나의 도구일 뿐이다. 

Self-management

점점 system의 규모가 커짐에 따라 사람이 모든 information system의 유지보수 및 설정관리에 어려움이 있다. SW규모가 커짐에 따라 분산된 환경에서도 system을 처리하기 어려움을 겪고, 이를 해결하기 위해서 self-management의 측면에서 system을 처리하자고 하였다. 이를 위해 autonomic computing perspective, self-organization perspective, ecological perspective 의 흐름으로 변해오는 과정을 설명할 것이다. 

3가지의 공통적인 특성인 self-* approach는 사람이 개입하지 않는 측면으로 보는 것이다. 모든 approaches는 사람이 개입되지 않고, 자동적으로 system을 수행 가능한 방향으로 발전해 왔다.   

Autonomic computing perspective (external management)

Autonomic computing perspective에서는 사람이 information system을 manage하지 않고 사람을 대신하여 대리의 autonomous manager를 두어 information system을 monitoring, configuration 그리고 maintenance activities하는 것이다.

장점	l  사람이 개입하지 않고 autonomous manager가 관리하며 self-management가 되었다. l  system마다 autonomous manager를 만듦으로써 Self-management system의 architecture가 매우 명확할 수 있다.
단점	l  System이 커지면 커질수록 autonomous manager와 system간의 분리는 heavy weight architecture가 될 수 있다.

Self-organization perspective (internal management)

Self-management를 위한 Self-organization perspective은 system이 스스로 self-manage의 기능을 할 수 있는 것이다. 각각의 컴포넌트가 하나의 개미라고 보고 전체의 개미 집합들은 각자의 interaction하는 룰에 따라 끊임없이 전체적인 패턴을 만들기 위해 reshaping한다.

장점	l  앞에서 본 system과 manager의 분리와 달리 light-weight architecture이다.
단점	l  개미 집합이나 곤충들의 집합에서 만약 문제가 생긴다면, 각자 manager를 가지고 있기 때문에 어디서 문제가 생겼는지 알 수 없다. l  현재의 접근방법으로는 개미들의 다양한 기능들을 컴퓨팅 시스템으로는 나타낼 수 없다.

Ecological perspective (external management)

앞에서 만약 어떤 문제가 생긴다면 어디서 문제가 발생했는지 모른다는 단점이 있었다. 이에 ecological perspective로 system들의 전반적인 행동들을 control하고 direct할 수 있는 manage component를 추가로 만들어 그 문제점을 해결한다는 것이다.

장점	l  Heavy weight architecture도 아니면서 전체 시스템의 전반적인 행동을 control 하고 manage 할 수 있다.

Aspect Oriented Programming(AOP)

Aspect Oriented Programming(AOP)  : 관점 지향 프로그래밍

등장 비경으로는 절차지향 -> 객체지향 프로그래밍(OOP) -> 관점지향 프로그래밍(AOP)

AOP는  Application을 다양한 관점(핵심 관심과 횡단 관심)으로 분해하여 객체지향에서 추구하는 모듈화하는 기법.

* 핵심 관심(core concerns) : 각 모듈에서 수행해야하는 기본적이고 대표적인 업무 기능.
* 횡단 관심(cross-cutting concerns) : 여러 개의 모듈에 걸치는 시스템의 부가적인 업무.

특징으로 보자면
 - 기능 분할로 핵심 관심 위주의 모듈 식별
 - 코드중복, 코드 산재 발생으로 복잡해짐(code tangling, code scattering)

Tangling이란 하나의 module안에 두개 이상의 concern이 연관되어 있을 경우를 말하며, 블록으로 칠해진 부분은 이 코드를 더 안전하게 security측면의 코드이다. 즉 이 모듈의 핵심 기능은 아니지만 전체 프로그램을 security를 높이는 것으로 하나의 module안에  핵심 코드와, security 코드가 같이 있는 것이다.

Scattering이란 하나의 concern이 여러개의 class에 영향을 주는 것으로, 하나의 기능을 하나의 모듈로 캡슐화 하지 못하고, 여러 모듈에 분산되어 코드가 반복적으로 나타나는 것이다. 이는 코드의 유지보수를 힘들게 한다.

나머지 정리는 http://seulkom.tistory.com/18 에 정리가 잘 된것 같다 ..

JAVA Performance Fundamental (chapter 2 . Run-time Data Areas)

chapter 2 . Run-time Data Areas

-       process로서 JVM이 프로그램을 수행하기 위해 OS로부터 할당 받는 메모리 영역이다.

-       각각의 목적에 따라 5개의 영역으로 나뉜다.

이중 PC Register와 두 개의 stack영역은 각 Thread별로 생성되며, Method Area와 Heap은 모든 Thread에게 공유된다.

① PC Register

-       각 thread마다 하나씩 존재한다.

-       thread생성될 때 같이 생성되며, native pointer와 return address를 가지고 있다. Thread가 java method를 수행할 때 현재 수행되고 있는 instruction의 주소를 포함하고 있고, 이 instruction의 주소는 native pointer일수도 있고 method bytecode의 시작점일 수도 있다.

-       Operand와 instruction을 저장해두는 별도의 메모리 공간.

② Java Virtual Machine Stacks

-       Thread의 수행정보를 기록하는 frame을 저장하는 메모리 영역이다.

-       Thread별로 존재하며 thread 시작될 때 생성된다.

-       Java Virtual Machine Stacks에 있는 모든 데이터는 각 thread가 소유하며, 다른 thread는 접근이 불가능하다.

* Stack Frame

Stack Frame은 Thread가 수행하고 있는 application단위로 기록하는 곳이다. Stack Frame은 Method를 실행하게 되면 Class의 메타 정보를 이용하여 적절한 크기로 생성된다. 그러나 이 stack frame의 크기는 가변이 아니며 compile time에 이미 결정된다. JVM은 생성된 Stack Frame을 Java Virtual Machine Stacks에 Push해 넣고 Method를 수행한다.

⑴Local Variable Section

-       Local Variable Section은 Method의 Parameter Variable과 Local Variable들을 저장한다.

-       Array로 구성되어 있고, index를 통해 Data를 찾아간다.

-       Method parameter는 선언된 순서로 인덱스가 할당되며, local variable은 compile가 알아서 인덱스를 할당한다.

⑵Operand Stack

-       JVM의 작업공간. JVM이 프로그램을 수행하면서 연산을 위해 사용되는 데이터 및 그 결과를 Operand Stack에 넣고 처리하기 때문이다.

⑶Frame Data

-       Constant pool resolution정보와 method가 정상 종료 했을 때의 정보들, 그리고 비정상 종료했을 시에 발생하는 exception관련 정보들을 저장하고 있다.

-       resolution이란, symbolic reference로 표현된 entry를 찾아 direct reference로 변경하는 과정이다. Class의 모든 symbolic reference는 method area의 constant pool이라는 곳에 저장되기 때문에 resolution을 constant pool resolution이라 하는 것이다.(symbolic reference를 실제 pointer로 변경한 작업)

③native Method Stacks

④method Area

-       모든 thread들이 공유하는 메모리 영역이다.

-       이 영역은 Load된 type을 저장하는 논리적 메모리 공간으로 정의할 수 있다.

-       JVM이 가동할 때 생성이 되며 Garbage Collection의 대상이 된다.

Constant pool

-       Type의 모든 상수(constant)정보를 가지고 있다.

-       JVM은 실행 시 참조하는 객체에 접근할 필요가 있으면 constant pool의 symbolic reference를 통해 해당 객체가 위치한 메모리의 주소를 찾아 동적으로 연결하게 된다.

⑤ Heap

-       Instance나 array가 저장되는 공간이며 모든 thread들에 공유된다.

-       JVM은 Heap에 메모리를 할당하는 instruction만 존재(new, newarray, anewarray, multianewarry)

-       메모리 해제를 위한 명시적인 java code나 byte code도 없으며 메모리 해제는 garbage collection을 통해 수행된다.

-       Java heap은 vendor마다 구조나 구현이 다르다.

`* VTable

클래스 내에 가상함수를 만들게 되면 컴파일러는 클래스에 가상함수테이블을 붙이게 된다. VTable은 함수를 가리키는 포인터 변수가 함수 개수만큼 존재하게 된다.. 다시 말해 실제 함수가 구현된 곳을 가리키는 포인터들의 집합.

Java의 variables

-       Class variables

-       Member variables

-       Parameter variables

-       Local variables