Chapter 10. JIT 컴파일의 세계로

[minkukjo]

JIT

• JIT Watch를 사용하면 핫스팟이 실제로 런타임에 바이트 코드에 무슨 일을 했는지 보여주는 도구라고 한다.
• JIT는 프로파일 기반의 최적화를 사용해 JIT 컴파일 여부를 판단함.
• 인터프리터와 C1 컴파일러는 JIT 컴파일러가 언제, 무슨 최적화를 할지 결정하는데 필요한 정보를 Method Data Object에 기록 해둔다.

인라이닝

• JIT는 인라이닝 기능을 제공하는데, 쉽게 얘기해서 함수를 호출하지 않고 함수의 내용을 그대로 호출부쪽으로 옮겨오는 기능이다. ( 코틀린에서는 inline이라는 키워드로 이것을 제공함 )

루프 펼치기

• 루프 내부의 메소드 호출을 전부 인라이닝 하면 루프 한 번 순회마다 얼마의 비용이 드는지, 반복되는 코드의 크기 등을 분석하기가 용이해짐.
• 이 정보를 토대로 매번 순회시 루프 처음으로 되돌아가는 횟수를 줄이기 위해 루프를 펼쳐서 최적화 한다.
• 이 짓을 항상 하는 건 아니고, 아키텍처, 핫스팟 버전에 따라 다름

탈출 분석

• 메서드 내부에서 할당된 객체를 메서드 범위 밖에서 바라볼 수 있는지를 알아보는 용도로 쓰임.
• 주로 객체가 메서드를 탈출하지 않으면, (NoEscape) VM은 객체 필드를 처음부터 객체 필드가 아닌 지역 변수였던 것 처럼 변환함.
• 결국 탈출 분석의 목표는 해당 객체의 힙 할당을 막음으로써 GC를 조금 더 덜 발생시키자는 취지로 보임.

단형성 디스패치

• 어떤 객체의 메서드를 호출할 때, 그 메서드를 최초로 호출한 객체의 런타임 타입을 알아내면 그 이후의 모든 호출도 동일한 타입일 가능성이 크다는 전제를 기반으로 한 최적화.
• 결국 이 추측을 토대로 JVM 내부에서 해당 객체 자체를 캐싱해서 klass 포인터나 vtable을 통해 가상 룩업 하는 일을 한 번만 수행하고자 하는 것이 목표. (최초에 호출한 클래스 이후에 모든 클래스가 같다면, 그 instanceOOP는 같은 klass 포인터를 바라보고 있을테니까)

인트린직

• JIT 서브시스템이 동적 생성하기 이전, JVM이 이미 알고 있는, 고도로 튜닝된 네이티브 메서드 구현체를 가르키는 용어.
• 네이티브 메서드라고 하니까 왠지 C나 C++로 개발되어있을 것 같은 느낌.

온-스택 치환

• 컴파일을 할 정도로 호출 빈도가 높지는 않지만, 메서드 내부에 핫 루프가 포함된 경우.
• 핫 루프가 무슨 뜻일까 생각해봤는데, 에제를 봤을 때는 횟수가 많은 루프문을 의미하는 것 같음.
• 이럴 경우 한계치를 초과하면 OSR(온스택치환)을 사용해 루프를 컴파일한 후 치환해서 실행한다고 함.

그 외

• 메서드를 작게 유지하면 인라이닝 가짓수가 늘어난다.
• JIT가 최적화할 여지를 주는 것이므로 메서드를 가급적 작게 유지하면 좋을 듯. ( 읽기도 좋고 )
• 실제로 메서드 바이트 코드 크기로 분석한 자료를 보면, 8000바이트 이하일 때와 8000바이트 이상일 대의 성능이 2배가까이 차이가 남을 알 수 있음.

GraalVM 관련

• https://www.graalvm.org/latest/reference-manual/native-image/
• https://www.graalvm.org/latest/reference-manual/native-image/basics/
• https://docs.spring.io/spring-boot/docs/current/reference/html/native-image.html
• https://meetup.nhncloud.com/posts/273

[HaeUlNam]

느낀점

JVM에서 굉장히 많은 최적화를 제공해주고 있어서, 단순히 코드만 보고 성능에 어떤 영향을 미치고 있는지 파악하긴 어려울 듯.

정리

JITWatch

• 반드시 HotPath에 있는 컴파일 대상 메서드를 분석 대상으로 삼아야 한다
• 아래 3가지 Vmoption을 enable해야 JITWatch가 제대로 동작
  • UnlockDiagnosticVMOptions, LogCompilation: 이 두 가지 옵션을 켜야 XML 형식의 Full JIT log가 남는다.
    • 아래 글에 따르면, 수백MB의 로그가 남을 수 있다는데 performance 이슈가 있을 수 있지 않을까?
    • https://www.oracle.com/technical-resources/articles/java/architect-evans-pt1.html
  • TraceClassLoading: Class가 load되는 시점을 알 수 있음
    • https://codingdog.tistory.com/entry/java-class-load-unload-%EC%9D%B4%EB%B2%A4%ED%8A%B8%EB%A5%BC-logging-%ED%95%B4-%EB%B4%85%EC%8B%9C%EB%8B%A4

Code Cache

• Java 9부터는 Segmented code cache가 도입. 네이티브 코드 유형마다 별도의 영역에 저장할 수 있음. 덕분에 단편화 및 sweeper 시간을 단축하고 풀 컴파일드 코드의 Locality를 높일 수 있게 되었음.
  • https://openjdk.org/jeps/197

JIT 컴파일

• Hotspot은 Profile 기반 최적화(PGO)를 이용해서 JIT 컴파일 여부를 판단
• 실행 프로그램 정보는 메서드 데이터 객체(Method Data Object)라는 구조체에 저장
• 최적화 기법
  • 인라이닝: 호출된 메서드의 content를 호출한 지점에 복사하는 것.
    • 어떤 메서드를 인라이닝할지?
      • 메서드의 바이트코드 크기
      • 현재 호출 체인에서 안라이닝할 메서드의 깊이
      • 메서드를 컴파일한 버전이 코드 캐시에 차지하는 공간
    • 인라이닝 서브시스템 튜닝
      • 중요 메서드가 인라이닝되지 않는 경우, 환경에 따라 이런 메서드까지 인라이닝되도록 적절히 JVM 매개변수를 조정해야 할 수 있다.
      • -XX:MaxInlineSize, -XX:FreqInlineSize 값을 바꿔보면서 성능이 조금이라도 나아지는지 확인
      • 바꿀 때는 반드시 측정 데이터를 근거로 삼아야 함. 실제 데이터를 제대로 보지도 않고, 특정 매개변수를 바꿨더니 효험이 있더라는 것은 스위치 만지작거리기 안티패턴의 전형
  • 루프 펼치기
    • 매번 순회할때마다 루프 처음으로 되돌아가는 횟수를 줄이기 위해 루프를 펼칠 수 있다.
    • Back branch가 일어나면 그때마다 CPU는 유입된 명령어 파이프라인을 덤프
  • 탈출 분석
    • 목표: 힙 할당을 막을 수 있는지 추론하는 것. 이를 통해 스택에 자동 할당되고, GC count를 줄임.
    • 할당된 객체가 메서드를 탈출하지 않는다는 사실을 밝히면 VM은 scalar replacement이라는 최적화를 이용해 객체 필드를 마치 처음부터 객체 필드가 아닌 지역변수였던 것처럼 스칼라 값을 변경.
    • → CPU 레지스터 속에 배치되거나 부족하면 Stack frame에 스칼라 값을 배치.
  • 락 성능 최적화
    • 비탈출 객체에 있는 락을 제거한다
    • 같은 락을 공유한, 락이 걸린 연속된 영역은 병합한다
    • 락을 해제하지 않고 같은 락을 반복 획득한 블록을 찾아낸다
  • 단형성 디스패치: 어떤 객체에 있는 메서드를 호출할 때, 그 메서드를 최초로 호출한 객체의 런타임 타입을 알아내면 그 이후의 모든 호출도 동일한 타입일 가능성이 높다.
  • 세이프포인트
    • 세이프포인트를 폴링하며 체크하는 비용 vs 이미 세이프포인트에 닿은 스레드가 다른 스레드로 세이프포인트에 모두 닿을때까지 대기.
  • 코어 라이브리러리 메서드가 JIT 컴파일에 주는 영향
    • 인라이닝하기 적합한 메서드 크기: JarScan 오픈소스로 limit 걸어서 넘어가는 method들 확인해볼 수 있음
    • 메서드를 작게 하면 인라이닝에 도움이 됨