java 핫스팟 컴파일

핫스팟 컴파일

핫스팟이란 이름은 코드 컴파일에 대한 접근법에서 유래했다고 합니다. 일반적인 프로그램은 전체 코드 중 일부만 자주 실행되며 애플리케이션의 성능은 이 일부가 얼마나 빠르게 실행되는가에 의해 좌우됩니다.

이 중요한 영역을 애플리케이션의 핫 스팟 이라고 합니다. 해당 영역의 코드가 많이 실행될 수 록 더욱 핫해집니다.
이런이유로 JVM은 코드를 실행할 때 바로 코드 컴파일을 하지 않습니다. 여기에는 기본적인 이유가 두가지가 있습니다.

1. 코드가 한번만 실행된다면 컴파일은 헛수고가 됩니다. 컴파일해서 컴파일된 코드를 한번만 실행하는 것 보다 자바 바이트 코드를 인터프리트하는 편이 더 빠를 것입니다.
2. 최적화 때문입니다. JVM이 특정 메소드나 루프를 실행하는 시간이 길어질 수록 코드에대해 얻어지는 정보가 많다. 이를 통해 JVM이 코드를 컴파일할 때 최적화를 많이 적용할 수 있습니다.

첫번째 이유의 경우 자주 호출되는 메소드거나 많이 반복되는 루프라면 컴파일할 가치가 있습니다. 컴파일러는 반드시 컴파일하기에 충분할 정도로 자주 호출되는 메소드를 알아낼 수 있습니다.

최적화 방법중 하나인 레지스트리와 메인 메모리 최적화 예시

public class RegisterTest{
    private int sum;

    public void calculateSum(int n){
        for(int i=0;i<=n;i++){
            sum += i;
        }
    }

}

위 예에서 인스턴스 변수인 sum은 메인 메모리에 있어야 하지만 메인 메모리에서 매번 값을 검색한다면 성능은 형편 없을 수 밖에 없습니다.

최적화를 한다면 컴파일러는 sum의 초기값을 레지스터에 로드하고 레지스터내의 값을 이용해 루프를 수행한 후 메인메모리에 결과 값을 저장할 것입니다.

이 최적화는 효과적이지만 스레드 동기화에서는 좀 다르게 적용될 것입니다. 스래드는 다른 스레드가 사용하는 레지스터의 값을 조회할 수 없기 때문입니다.

동기화를 한다면 레지스터에서 메인 메모리로 저장되어 다른 스레드들이 이용 가능한 시기를 알려줘야 합니다.

b = obj1.equals(obj2); 

위 예제의 equals() 메소드는 모든 자바 객체에서 사용할 수 있는 메소드이며 흔히 오버라이드됩니다.
인터프리터는 위 문장에 맞닥뜨릴 때 실행시킬 equals() 메소드가 뭔지 알기 위해서 obj1의 타입을 찾기위해 동적 look up을 해야합니다. 이때 많은 리소스가 필요합니다.
시간이 흘러 이문장을 많이 실행해 봤고 매번 obj1의 타입이 java.lang.String이라는 사실을 알게 됬다면 그때 JVM은 obj1.equals()를 String.equals()로 최적화한 코드를 만들 수 있다.