탄생배경
https://www.youtube.com/watch?v=UzaGOXKVhwU 참조
C/C++ 는 컴파일 플랫폼과 타켓 플랫폼이 다를 경우 ,프로그램이 동작하지 않는다.
플랫폼 : 운영체제 + CPU 아키텍쳐 (INTEL , AMD 등)
운영체제에 따라 또는 CPU 아키텍쳐에 따라 기계어를 해석하는 방식이 다 다르기 때문에.
Mac 에서 개발한 컴파일한 프로그램을 Linux 또는 Windows 에서 실행할 경우 돌아가지 않는다.
해결방법 - 크로스 컴파일
근본적으로 해결한 JVM
전자는 프로그램이 플랫폼에 의존 한다면, 자바는 프로그램 즉 자바 바이트코드는(javac 로 생성된) 타켓 플랫폼에 의존 하지 않고 JVM 이 대신 타켓플랫폼에 의존한다.
개발자 입장에서는 해당 플랫폼에 맞는 JVM 만 설치되어있다면 어떤 플랫폼에서든 프로그램을 돌릴 수 있다.
자바코드가 실행 되기 까지
C나 C++ 같은 경우는 컴파일러가 전체 행위(프론트 ,백 파트)를 다 하지만 자바는 구문을 추상화하고 분석하는 역할의 프론트와 분석된 구문을 해당 플랫폼에 맞는 어셈블리어로 바꿔주는 백의 파트를 구분해서 (javac - JVM) 구현 했다.
장점 : rumtime 에서 발생되는 소중한 정보를 가지고 최적화를 하는 JIT 컴파일러 구현.
메모리 구조
<스레드 공유>
Method Area : 클래스 로더가 클래스 파일을 읽어오면 , 클래스 정보를 파싱해서 Method Area 에 저장한다.
Heap : 프로그램을 실행하면서 생성한 모든 객체를 Heap 에 저장한다.
<각스레드마다 존재>
Program Counter : 각 스레드는 메서드를 실행 하고 있고 ,pc 는 메서드 안에서 몇번째 줄을 실행해야 하는지 나타내는 역할
Stack : 자바 스택은 스레드 별로 1개만 존재. 스택 프레임은 메서드가 호출 될 때마다 생성된다. 메서드 실행이 끝나면 스택프레임은 pop 되어 스택에서 제거된다.
native method stack : java bytecode 가 아닌 다른 언어로 작성된 메서드를 의미한다.
(성능향상으로 컴파일 해서 사용 하는 경우가 있다.)
Specification
표준
-> 누구든 '무엇' 의 표준을 만족하는 '무언가'를 만든다면 그 '무언가' 는 '무엇'이다.
-> 누구든 'JVM' 의 표준을 만족하는 '무언가'를 만든다면 그 '무언가' 는 'JVM'이다.
JVM 은 표준의 역할을 하는 Specification 이 존재한다.
고로 JVM 은 누구나 만들 수 있으며 , Specifiation을 만족하는 구현체(JVM)를 만들어 배포하는 조직이나 사람들을 Vendors 라고 한다.
https://www.youtube.com/watch?v=6reapO0gLPs 참조
-> 누구든 'JVM' 의 표준을 만족하는 '무언가'를 만든다면 그 '무언가' 는 'JVM'이다.
여기서 무언가는 소프트웨어 뿐만이 아니라 하드웨어도 가능하다.(이론상으로)
실제
byte code 를 직접 실행하는 마이크로 프로세서를 만들기도 하였다.(실행엔진 부분)
이러한 시도들은 실패했거나 , 시장성이 없어 살아남지 못했다...
<정리>
-> 누구든 JVM 을 만들 수 있으며, 구현된 형태에 대해서는 어떠한 제약도 없다. (Specification 을 만 족한 상태에서 )
Specification 과 가장 유사한 JVM 구조
의문점
가비지 컬렉터 , JIT 컴파일러 같은 성능 최적화의 핵심 요소들은 어디 갔죠?
의문점에 대한 공식 입장
https://www.youtube.com/watch?v=6reapO0gLPs 참조
추상
JVM Specification 문서는 상당히 많은 부분들이 추상적으로 작성되어있다.
JVM 의 추상화/다형성 으로부터 얻을 수 있는 장점을 폭넓게 누릴 수 있도록 고안되어있다.
(Vendor 들의 창의성 , 자율성을 해치는 것을 최대한 감소)
현재의 JVM 은 폭넓은 재량 하에 이루어진 구현자들의 고민과 노력의 산물이다.
