JVM 메모리 구조와 연산

#

  JVM의 메모리 구조

일반적인 프로그램과 자바 프로그램의 구조입니다.

사용자가 작성한 JAVA 코드(JAVA Source)를 컴파일러(Java Compiler)가 바이트코드로 변환시켜준다. 변환된 바이트 코드는 Execution Engine에 의해 처리된다.

#JVM의 메모리 구조

  Method Area

1. Field Information : 멤버변수의 이름, 데이터 타입, 접근 제어자에 대한 메타데이터

2. Method Information : 메서드의 이름, 리턴타입, 매개변수, 접근제어자에 대한 메타데이터

3. Type Information : Type의 속성이 Class인지 Interface인지의 여부 저장

' 접근 제어자 및 연관된 interface의 전체 리스트 저장 //abstract여서 @Overrinding 한 메소드를 찾아야 하기 때문

4. 리터럴 풀(Constant Pool)

' 필요시 상수를 저장하거나 사용하는 공간

5. Class 사용 이전에 메모리 할당

' final class 변수의 경우(상수로 치환되어) 상수 풀에 값 복사

*모든 쓰레드가 공유한다.

#JVM의 메모리 구조

  Stack Area

' 메서드 호출 시마다 각각의 스택프레임이 생성

' 호출된 메서드의 매개변수, 지역변수, 리턴 값 및 연산 시 일어나는 값들을 임시로 저장

' 메서드 수행이 끝나면 프레임별로 삭제

' 쓰레드별로 1개씩 스택이 생성된다.

#JVM의 메모리 구조

  Heap Area

- 인스턴스가 생성되는 공간

#JVM의 메모리 구조

  PC Register

Thread가 생성 될 때마다 생성되는 공간이다. Thread가 어떤 부분을 어떤 명령으로 실행할 지에 대한 기록한다. 현재 실행되는 부분의 JVM의 주소와 명령어를 저장한다.

#JVM의 메모리 구조

  Native Area Method

자바 외의 다른 언어에서 제공되는 메서드들이 저장되는 공간이다.

근데 왜 굳이 저런 구조를 택했어야 했을까?

Green팀의 프로젝트는 결국 [휴대용 장치 + 운영체계 + Oak로 작성된 애플리케이션]을 만들어 보겠다는 것이었습니다. 오늘날, 휴대폰이나 PDA에 인터넷 관련 기능을 첨가하는 데 있어 자바가 중요한 역할을 하게 될 거라는 말이 종종 들려 오는 까닭은 이처럼 자바가 개발 당시부터 Post PC 어플라이언스를 대상으로 만들어진 언어였기 때문입니다.

일반 소비자를 대상으로 한 프로젝트에서 출발한 "Oak"는 자연스럽게 현재의 자바가 강점으로 내세우는 여러 가지 특징을 개발 당시부터 요구받게 되는데요.

첫째, 절대 충돌이나 다운이 되어서는 안되겠다는 것 : 자바는 C++ 에러의 가장 큰 원인인 포인터(pointer)를 없애서 안정성을 기합니다.

둘째, 씨피유에 상관없이 플랫폼 독립적이어야 한다 : 왜냐하면 그런 휴대용 장치는 여러 회사에서 여러 종류의 칩을 사용해서 만들어질 가능성이 컸기 때문입니다.

셋째, 네트워크에 적합해야 한다.

출처: http://stage-diary.tistory.com/128?category=970690 [꽃이 흘러 내리는 나만의 스테이지]

라는 조건을 만족해야했습니다.

저 조건을 만족시키기에는 저런 구조가 요구사항을 들어주기에 최적의 방식이었던 것입니다.