GraalVM의 VM은 JVM 내부에서 실행된다는 사실에서 비롯 되었으며 GraalVM은 Oracle이 만든 JVM과 JDK으로 애플리케이션 성능과 효율성의 향상을 제공하는 고성능 런타임이다.
GraalVM의 특징 은 아래와 같다.
-
자바로 만들어진 새로운 JIT 컴파일러
(Graal을 기반으로하는 고성능 자바) -
AOT 네이티브 이미지 컴파일러 - 워밍업 시간 단축 - 서버리스에 적합
(Native 자바의 특성을 통해서 빠른 startup time을 제공) -
폴리그랏
(Ployglot을 기반으로 다양한 언어의 통합)
AOT 네이티브 이미지 컴파일러
GraalVM의 다양한 시도와 도전은 최근 클라우드 시대에 IT 환경에서 꼭 필요한 기능들입니다.
GraalVM의 가장 큰 핵심은 AOT 컴파일러입니다.
AOT컴파일러는 코드를 최적화하고 컴파일 후 네이티브 코드로 제공된다.
가장 큰 특징은 네이티브 이미지 컴파일이 가능하다는 것이었고 이말은 Java가 바이너리 파일을 만들수 있다는 의미.
Native Image? Native Image는 Java code를 미리 바이너리(Native executable)로 컴파일 하는 기술
Native Image Bulider
Java code ---------------------------> executable
Native Image Generator
이렇게 생성된 실행파일(Native executable)은 필요한 '리소스의 일부만을 사용'해서 빠르다는 장점이 있다.
그렇다면 어떻게 '리소스의 일부만을 사용'할까?
정적 분석(Static Analystic)
정적분석이란 애플리케이션에서 사용되는 프로그램 요소(class, method, 및 field)를 결정하는 프로세스
이렇게 정적분석이라는 프로세스를 통해 필요한 리소스를 스캔하게 된다.
어떻게?
Java code -> byte code(class file)을 스캔
네이티브 이미지 힙이라는 메모리 영역에서 루트객체(main)부터 스캔 -> 연결할수 있는 클래스 확인
-> 새로 검색된 요소는 추가 스캔(즉, 요소의 도달 가능성 반복적으로 스캔)기존 JAVA JVM의 고질적인 문제는 시동시간
VM을 반복해서 종료, 그리고 요청이 왔을 때 구동 -> 대략 3초의 시간이 필요했지만,
사실 모든 GET요청에 예를들어 Spring Boot의 모든 기능이 필요하지 않다.이와 함께 클라우드 네이티브 프레임워크를 이용하면 0.005초에 응답하는 (서버리스) Lambda 함수를 만들 수 있다.
마냥 전체 리소스를 모두 가동하는데는 오히려 느릴 수 있다 (스캔시작때문). 하지만 현대 서버리스적 관점에서 앞서말한 이점중 시작시간의 단축에서 가격감소 그리고 get하나에 모든 리소스가 필요할까에 대한 답안을 제공한다.
다국어지원
Truffle은 GraalVM의 다국어를 전담한다. Javascript, Ruby, R 및 모든 LLVM 언어의 영역이다. LLVM 컴파일러는 C코드를 LLVM 비트 코드로 변환하여 GraalVM에서 실행되게 만든다.
자바나 스칼라 같은 JVM 기반 언어는 GraalVM JIT컴파일러의 최적화를 통해 성능 향상을 기대할 수 있습니다. 그 위에 Truffle 프레임워크가 올라가는데, 이는 자바스크립트, R, 파이썬, 루비 등 JVM 기반이 아닌 기존 언어의 새로운 구현을 지원합니다.
왜 오라클은 GraalVM을 만들었을까?
1999년 C++의 Hotspot 컴파일러는 JVM의 상징적인 존재였습니다.
지난 20년간 HotSpot 컴파일러는 자바의 성능을 굉장히 향상시켜주었지만 기술부채로 인해 추가적인 성능개선이 어려운 상황입니다. 즉, 기존 Hotspot컴파일러는 C/C++로 작성되어 있지만 Java로 JVM 컴파일러를 다시 작성하면 새로운 기회가 열립니다.
어떻게?
GraalVM은 새로운 아이디어를 바탕으로 이 문제에 대한 새로운 해석을 가지고 있다.
GraalVM JIT 컴파일러는 자바 9 버전에 추가된 JVMCI(JVM Compiler Interface)를 이용하여 기존 핫스팟 런타임에 플러그인 되는 구조로 동작합니다. 이와 같이, 최적화같은 성능 향상 뿐만 아니라 인터페이스 확장성을 염두해두고 만들어졌기 때문에 지속적인 성능개선이 가능해집니다.
뿐만아니라 meta-circular Java가 가능해집니다.
Meta-circular Java?
자바로 만들어진 새로운 JIT 컴파일러
meta-circular 스타일이란 언어를 실행하는 환경과 코드를 개발하는 언어가 같은 스타일을 의미합니다. PyPy와 같이 파이썬으로 만든 파이썬이 meta-circular 구현체의 대표적인 예입니다.OpenJDK의 서브 프로젝트인 GraalVM의 목표는 Meta-Circular 자바의 구현과 C2 JIT 컴파일러를 Graal로 대체하는 것
Graal의 포지션
--- GraalVM이 왜 필요한가
지난 몇년간 OpenJDK가 6개월마다 새로운 버전을 공개하며 Agile한 개발 프로세스를 가져왔습니다.
Java가 빠르게 변화하는 IT 환경에 효과적으로 대응해옴.
그러나 개발 기간이 짧아지면서 그만큼 개발과정에서 시행착오를 경험하고 검증할 시간이 부족.
그러면 어떻게 해야 할까?
Java는 이미 답을 Java Framwork인 Spring과 Hibernate에서 찾을 수 있었습니다.
Java EE 5 이후 SpringFramework와 Hibernate와 같은 유명 오픈소스에서 검증된 기술이 JavaEE에 표준으로 들어가는 방식을 체험하고 경험
![[JavaEE5 이후에 만들어진 JCP와 오픈소스 커뮤니티의 선순환 구조.png]]
이런 흐름은 기술개발, 검증, 표준화의 선순환 구조를 만들고 확대
이와 같이, GraalVM에서 실험하고 검증한 기술을 OpenJDK에 추가하고 다시 유지보수 성격이 강한 Oracle Java에 적용
GraalVM (EE, CE) -----> OpenJDK ------> Oracle JAVA
Graal 또한 EE와 CE가 있으며 Enterprise Edition이 Community Edition보다 약 30% 정도 더 성능이 높다
| Java | 특징 | 신기술 적용 방식 |
|---|---|---|
| Oracle Java | OpenJDK의 엔터프라이즈 버전 | 보수적이고 신중하게 버그 개선, 오류에 대한 Fix에 중점 |
| OpenJDK | 표준 자바 | Java Spec과 표준화된 기능 추가 및 기능 개선에 중점 |
| GraalVM | 다양성 자바 | 신기술 및 새로운 개념 및 기법을 적용, 새로운 변화를 적극적으로 반영 |
GraalVM CE를 활성화해 자바에 대한 새로운 시도와 완성도에 대한 다양한 피드백을 받고, 이결과를 OpenJDK에 반영하고 지속해서 효과적인 자바 개발의 선순환 구조를 유지할 것 같다(개인적인 의견)
그렇기에 GraalVM CE를 없애기 보다는 더 많이 확산시키는 쪽으로 움직일 것
참조
https://www.graalvm.org/latest/reference-manual/native-image/
https://lab.logpresso.com/2020/05/10/graalvm
http://taewan.kim/graalvm/position_of_graalvm/
https://giljae.medium.com/graalvm-%EC%86%8C%EA%B0%9C-84ac547f8df2
https://www.youtube.com/watch?v=C7toO3WV1NQ
https://www.youtube.com/watch?v=4lQ-sTDlgIo
