Compiler :
직역하면 “해석기” 라는 의미를 가지고 있습니다!
즉, 저희가 일상생활에서 쓰는 언어인 “Hi ! What is your name?” 과 같은 언어를 기계가 이해할 수 있는 언어로 해석해주는 일종의
번역? 프로그램인거죵.
정확히 말하자면, 사람의 언어를 기계가 이해할 수 있는 기계어로 해석해주는 프로그램입니다.
자바에서 저희가 직접 작성하는 코드의 소스파일이 “사람의 언어”
컴파일을 하여 나온 언어가 목적파일 “기계어” 라고 생각하면 되죠.
그렇다면, 자바에서는 소스파일이 어떠한 형태를 가진 목적파일로 변환이 될까요?
.java → Byte Code
자바 소스파일은 C, C++과 다르게 바이너리 코드가 아닌 바이트 코드의 파일로 변환하게 됩니다.
여기서 변환된 바이트코드의 파일이 바로 .class를 가르키는거죠!
이러한 변환을 도와주는 아이를 “자바 컴파일러” 라고 부릅니다.
<aside> 💡 “자바 컴파일러” 는 파일을 실행시키는 개념이 아닙니다. 변역을 해주는 개념이죠. 그래서 많은 분들이 헷갈리고 착각하시는게 “자바는 컴파일 방식이야!”
</aside>
라고 하는겁니다. 실제로는 그렇지 않습니다. 하이브리드에요……
바이트 코드로 언어를 해석할때는 “컴파일”
JVM에서 프로그램을 실행시킬때는 “인터프리터” 입니다.
JVM : Java Virtual Machine
그렇다면 이렇게 바뀐 .class를 가지고 실제로 컴퓨터에서 실행을 시켜야 겠죠?
그 역할을 수행하는 아이가 바로 “JVM”입니다.
근데 여기서 주의해야 될게 있습니다.
자바는 컴파일러가 인간의 언어를 “기계어” (.class) 로 변환시켜서 그 파일을 실행한다라고 하는데,
사실 정확하지는 않습니다. 무슨 말이냐고요?
컴파일러에 의해 변환된 .class파일은 완전한 기계어가 아닙니다.
이게 뭔소리야…….
라는 생각이 분명 들겁니다. 앞서 말햇듯이 “기계어”로 변환시킨다고 말을 해놨으니까요!
근데 잘 생각해보면 이해가 갑니다.
“아니 그러면 기계어로 바꿨으니까 그냥 실행 시키면 되는거 아니야? 왜 굳이 JVM에서 실행을 시켜야 되는건데????”
그쵸…이게 핵심이죠.
자바 컴파일러를 통해 변환된 .class파일은 JVM이 읽을 수 있는 파일인겁니다. (바이트 코드로 이루어짐)
운영체제가 다른 “기계”에서는 읽을수가 없는 파일인거죠….
그러한 단점을 보완하고 극복하고자 하는게 바로 “JVM” 입니다.
JVM이 하는 역할
JVM은 .class 파일을 사용자의 운영체제에 맞는 실행환경을 제공합니다.
어떻게 가능하냐고요? JVM이 운영체제마다 달라요 ^^. 간단하죠?
즉 자바는 플랫폼에 종속적이지 않지만, JVM은 플랫폼에 종속적인 성향을 가지고 있습니다.
즉 리눅스의 JVM과 윈도우의 JVM은 서로 다릅니다.
자바로 작성된 모든 프로그램은 자바 가상 머신에서만 실행될 수 있으므로, 자바 프로그램을 실행하기 위해서는 반드시 자바 가상 머신이 설치되어 있어야 합니다!!
그래서 각자 운영체제에 맞는 JVM이 있다면 똑같은 자바 파일로 여러 운영체제에서 실행이 가능한 이유죠 🙂
Compiler :
직역하면 “해석기” 라는 의미를 가지고 있습니다!
즉, 저희가 일상생활에서 쓰는 언어인 “Hi ! What is your name?” 과 같은 언어를 기계가 이해할 수 있는 언어로 해석해주는 일종의
번역? 프로그램인거죵.
정확히 말하자면, 사람의 언어를 기계가 이해할 수 있는 기계어로 해석해주는 프로그램입니다.
자바에서 저희가 직접 작성하는 코드의 소스파일이 “사람의 언어”
컴파일을 하여 나온 언어가 목적파일 “기계어” 라고 생각하면 되죠.
그렇다면, 자바에서는 소스파일이 어떠한 형태를 가진 목적파일로 변환이 될까요?
.java → Byte Code
자바 소스파일은 C, C++과 다르게 바이너리 코드가 아닌 바이트 코드의 파일로 변환하게 됩니다.
여기서 변환된 바이트코드의 파일이 바로 .class를 가르키는거죠!
이러한 변환을 도와주는 아이를 “자바 컴파일러” 라고 부릅니다.
<aside> 💡 “자바 컴파일러” 는 파일을 실행시키는 개념이 아닙니다. 변역을 해주는 개념이죠. 그래서 많은 분들이 헷갈리고 착각하시는게 “자바는 컴파일 방식이야!”
</aside>
라고 하는겁니다. 실제로는 그렇지 않습니다. 하이브리드에요……
바이트 코드로 언어를 해석할때는 “컴파일”
JVM에서 프로그램을 실행시킬때는 “인터프리터” 입니다.
JVM : Java Virtual Machine
그렇다면 이렇게 바뀐 .class를 가지고 실제로 컴퓨터에서 실행을 시켜야 겠죠?
그 역할을 수행하는 아이가 바로 “JVM”입니다.
근데 여기서 주의해야 될게 있습니다.
자바는 컴파일러가 인간의 언어를 “기계어” (.class) 로 변환시켜서 그 파일을 실행한다라고 하는데,
사실 정확하지는 않습니다. 무슨 말이냐고요?
컴파일러에 의해 변환된 .class파일은 완전한 기계어가 아닙니다.
이게 뭔소리야…….
라는 생각이 분명 들겁니다. 앞서 말햇듯이 “기계어”로 변환시킨다고 말을 해놨으니까요!
근데 잘 생각해보면 이해가 갑니다.
“아니 그러면 기계어로 바꿨으니까 그냥 실행 시키면 되는거 아니야? 왜 굳이 JVM에서 실행을 시켜야 되는건데????”
그쵸…이게 핵심이죠.
자바 컴파일러를 통해 변환된 .class파일은 JVM이 읽을 수 있는 파일인겁니다. (바이트 코드로 이루어짐)
운영체제가 다른 “기계”에서는 읽을수가 없는 파일인거죠….
그러한 단점을 보완하고 극복하고자 하는게 바로 “JVM” 입니다.
JVM이 하는 역할
JVM은 .class 파일을 사용자의 운영체제에 맞는 실행환경을 제공합니다.
어떻게 가능하냐고요? JVM이 운영체제마다 달라요 ^^. 간단하죠?
즉 자바는 플랫폼에 종속적이지 않지만, JVM은 플랫폼에 종속적인 성향을 가지고 있습니다.
즉 리눅스의 JVM과 윈도우의 JVM은 서로 다릅니다.
자바로 작성된 모든 프로그램은 자바 가상 머신에서만 실행될 수 있으므로, 자바 프로그램을 실행하기 위해서는 반드시 자바 가상 머신이 설치되어 있어야 합니다!!
그래서 각자 운영체제에 맞는 JVM이 있다면 똑같은 자바 파일로 여러 운영체제에서 실행이 가능한 이유죠 🙂
JVM이 바이트 코드를 읽는 방식
“인터프리터” 방식으로 바이트 코드를 한 줄씩 해석, 실행 하는 방식입니다.
아무래도 해석, 실행을 계속 반복하다보니 속도가 매우 느리겠다는 단점이 있겠죠?
근데 저희가 알기로는 자바는 “컴파일 방식으로…….” 라고 알고있습니다… 뭘까요 뭐가 맞는거여;
초기 방식은 “Interperter”, 보완된 방식이 “JIT” 컴파일 방식.
맞아요. 자바의 초창기에는 오로지 인터프리터 방식으로 코드를 해석, 실행했기에 속도가 느려서, 추후에 속도를 보완하기 위해서 나온것이
바로 JIT컴파일 방식입니다🙂
JIT (Just In Time) 방식
기존의 자바는 명렁어를 하나씩 해석하고 실행하게끔 이루어져 있어서 속도가 매우 느렸습니다.
하지만 하드웨어적인 발전이 이루어지면서, 자바 컴파일러도 JIT컴파일러 방식으로 개선되어서 속도적인 측면에서
많은 발전을 이루었죠!!
JIT컴파일러는 “똑같은” 코드를 매번 해석하지 않고, 실행할 때 컴파일을 하면서 해당 코드를 캐싱합니다.
즉 기억해놓는거죠??? 그 이후에 바뀐 부분만 컴파일을 하고, 나머지는 이미 캐싱이 된 코드를 사용하는거죠.
성능상으로 10~20배 정도 좋아졌답니다 올…….
하지만 항상 JIT 컴파일러 방식이 작동하는건 아닙니다. 특정 이상의 성능을 요구 하는 작업에서만 작동을 한다고 합니다 😟
<aside> 💡 결론 : 자바 컴파일러 ⇒ .class 파일 ⇒ JVM ⇒ JIT 컴파일 + 인터프리터 형식 ⇒ 각 운영체제에 맞게 실행
</aside>
즉 JVM이 이해하기 위한 컴파일 과정 한번, 각 운영체제에 디바이스가 이해하기 위한 컴파일 or 인터프리터 과정 한번 으로 총 두번의 컴파일이 일어 날 수 있다.
자바는 이러한 이유로 하이브리드 언어라고 말해지네요… 헷갈리지 맙시다 😟
JVM이 바이트 코드를 읽는 방식
“인터프리터” 방식으로 바이트 코드를 한 줄씩 해석, 실행 하는 방식입니다.
아무래도 해석, 실행을 계속 반복하다보니 속도가 매우 느리겠다는 단점이 있겠죠?
근데 저희가 알기로는 자바는 “컴파일 방식으로…….” 라고 알고있습니다… 뭘까요 뭐가 맞는거여;
초기 방식은 “Interperter”, 보완된 방식이 “JIT” 컴파일 방식.
맞아요. 자바의 초창기에는 오로지 인터프리터 방식으로 코드를 해석, 실행했기에 속도가 느려서, 추후에 속도를 보완하기 위해서 나온것이
바로 JIT컴파일 방식입니다🙂
JIT (Just In Time) 방식
기존의 자바는 명렁어를 하나씩 해석하고 실행하게끔 이루어져 있어서 속도가 매우 느렸습니다.
하지만 하드웨어적인 발전이 이루어지면서, 자바 컴파일러도 JIT컴파일러 방식으로 개선되어서 속도적인 측면에서
많은 발전을 이루었죠!!
JIT컴파일러는 “똑같은” 코드를 매번 해석하지 않고, 실행할 때 컴파일을 하면서 해당 코드를 캐싱합니다.
즉 기억해놓는거죠??? 그 이후에 바뀐 부분만 컴파일을 하고, 나머지는 이미 캐싱이 된 코드를 사용하는거죠.
성능상으로 10~20배 정도 좋아졌답니다 올…….
하지만 항상 JIT 컴파일러 방식이 작동하는건 아닙니다. 특정 이상의 성능을 요구 하는 작업에서만 작동을 한다고 합니다 😟
💡 결론 : 자바 컴파일러 ⇒ .class 파일 ⇒ JVM ⇒ JIT 컴파일 + 인터프리터 형식 ⇒ 각 운영체제에 맞게 실행
즉 JVM이 이해하기 위한 컴파일 과정 한번, 각 운영체제에 디바이스가 이해하기 위한 컴파일 or 인터프리터 과정 한번 으로 총 두번의 컴파일이 일어 날 수 있다.
자바는 이러한 이유로 하이브리드 언어라고 말해지네요… 헷갈리지 맙시다 😟
'Java' 카테고리의 다른 글
| Static 이란? (0) | 2023.01.13 |
|---|---|
| 2ndArray 2차원배열 (0) | 2023.01.13 |
| AutoBoxing, AutoUnboxing 이란? (0) | 2023.01.13 |
| JAVA 객체지향프로그래밍 ⇒ OOP? (0) | 2023.01.13 |
| JAVA Generic (제너릭) 이란 (0) | 2023.01.13 |
