- *JIT(Just In Time Compiler 개념 및 튜닝)
- 한 번만 실행될 코드라면 인터프리터가 빠르다, 하지만 많이 실행될 코드라면 컴파일을 하는것이 좋다.
- JIT(그때그떄, 그래서 언제?)
- 핫스팟 JVM은 코드를 바로 컴파일 하지 않는다.
- 먼저 인터프리터가 동작하여 코드를 실행한다.
- 일정시간 동안, 인터프리터가 코드를 해석하며 컴파일하기에 충분할정도로 자주 호출되는 메소드가 무엇인지알아내고 해당 메소드만 컴파일한다.
- 그리고 최적화도 수행한다.
- *JVM 컴파일러 최적화 무엇을? 어떻게?
- b = obj1.equlas(obj2)
- 위 코드에서 obj1타입에 따라 동작이 달라진다.
- 떄문에 Dynamic Lookup이 필요한데, 다이나믹 룩업은 해당 오브젝트 타입을 실행시간에 결정하는것으로 매우 느리다.
- jvm obj1이 String이란것을 안다면, 동적 룩업하지 않고 String.equals() 메소드를 호출하도록 컴파일 한다. 하지만 다른 가능성도 열어두고 컴파일한다.
- 컴파일된 코드는 코드캐시라는곳에 올라가며, 프로그램이 멈추지 않고도 컴파일된 코드가 바로 적용 가능하다.
- 즉, JIT은 코드캐시라는 곳에 자주 사용하는 컴파일된 코드를 저장하며, 이곳에는 컴파일된 코드들은 자주 사용되는 코드들을 동적으로 바뀌며, 바뀌더라도 프로그램이 정지하지 않고 동작한다.
- 컴파일 튜닝이란?
- 일정기간 자주 사용하는 메소드들을의 기간을 JVM 옵션을 통해 설정가능하다,
- 컴파일된 코드가 올가는 코드캐시의 크기도 설정 가능하다. 이러한 컴파일 관련 설정들은 옵션을 통해 바꿀수 있으며 이러한 작업이 컴파일 튜닝이다.
- -XX:ReservedCodeCacheSize=N
- -XX:InitialCodeCacheSize=N
- 캐시의 크기 조정은 백그라운드에서 동작하며 성능에 영향을 주지 않는다.
- 컴파일 임계치란?
- 컴파일 임계치 = method entry counter + back-edge loop counter
- 많이 사용되는 메서드들을 컴파일한다
- 많이 사용된다는 기준이 컴파일 임계치이다.
- 메서드가 호출된 횟수, 메소드 내의 루프가 있다면 루프를 빠져 나오기까지 돈 횟수 두 개를 기반으로 측정한다.
- 두 카운터의 합계를 확인하고 메소드가 컴파일될 자격이 있는지 결정한다.
- 자격이 있다면 컴파일되기 위해 큐에서 대기한다.
- 큐에 있는 메서드들은 컴파일 스레드에 의해 컴파일된다.
- OSR : On - Stack Replacement
- 처음 실행됐지만, 루프가 정말 길 경우 중간에 컴파일될 필요가 있다. 그래야 남은 반복을 빠르게 실행할 수 있다.
- 따라서 루프의 실행을 그때그때 카운트하고 임계치를 넘게 되면 전체 메서드가 아닌 루프만을 컴파일하여 컴파일된 버전을 바로 실행시킨다.
- 스택상에서 컴파일된 버전을 바로 실행시키는 것을 OSR이라고 한다.
- -XX:CompileThreshold=N
- 컴파일 임계치를 지정한다.
- 클라이언트 컴파일러에서 기본 값은 1,500
서버 컴파일러의 기본 값은 10,000
- 컴파일 임계치를 변경하는 것은 권고된다
- 애플리케이션이 워밍업 하는데 필요한 시간을 절약한다
- ==> 어차피 10,000번 실행돼서 컴파일될 코드는 8,000번으로 줄여도 큰 차이 없다
- 절대로 컴파일되지 않을 일부 서버 메서드들을 컴파일할 수 있다
- ==> 컴파일 임계치에 가까이 있지만, 아슬아슬하게 걸쳐서 컴파일되지 않는 것들을 컴파일해서 실행 속도를 높일 수 있다.
- 카운터 값은 최근 일정 기간에 대한 상대적 측정값이다.
- 따라서 lukewarm method(긴 시간에 걸쳐서 많이 호출되는 메서드)들은 카운터 값이 낮을 수밖에 없다. 따라서 컴파일 임계치를 낮춰서 컴파일을 해주는 것이 더 좋다.