초록
자바에서는 어떤 객체에 접근하는 작업을 할 때마다 항상 해당 객체에 대한 레퍼런스가 널 (Null)인지 여부를 먼저 검사하도록 규정하고 있다. 자바 언어는 객체 중심 언어이기 때문에 객체 접근이 빈번하며 이러한 널 포인터 검사는 자바 프로그램의 성능을 크게 저하시킬 수 있다. 이러한 성능 저하를 줄이기 위한 방법으로 불필요하게 반복되는 널 포인터 검사를 제거하는 기법이 사용되고 있다. 즉, 적시 (Just-in-Time, JIT) 컴파일러가 사용되는 자바 수행 환경에서 코드 분석을 통해 불필요한 널 포인터 검사 코드를 제거하는 최적화를 한다. 본 논문은 JIT 컴파일러 수행 환경에서 조건 수행(predication)이라는 최근 마이크로프로세서의 특징을 이용하여, 기존의 최적화로는 제거할 수 없는 널 포인터 검사 코드를 추가로 없애는 방법을 제시한다. 일반적으로 널 포인터 검사 코드는 비교와 분기 두 명령어로 이루어져 있는데, 그 중에 비교 명령어를 객체를 사용하기 전에 수행하는 것이 아니라 객체가 정의된 직후에 미리 수행하도록 함으로써 널 포인터 검사를 위해 수행되는 총 비교 명령어 수를 줄이는 것이 이 방법의 주된 내용이다. 실험 결과 기존의 널 포인터 제거로 최적화된 코드에 비해 수행된 비교 명령어의 수는 SPECjvm98에서 평균 3.21$\%$줄었고, 생성된 비교 명령어 수는 1.98$\%$ 줄었다. 이는 인텔 IA-64 아이테니엄(Itanium) 컴퓨터에서 평균 0.32$\%$의 성능 향상을 가져왔다.
Java specification states that all accesses to an object must be checked at runtime if object refers to null. Since Java is an object-oriented language, object accesses are frequent enough to make null pointer checks affect the performance significantly. In order to reduce the performance degradation, there have been attempts to remove redundant null pointer checks. For example, in a Java environment where a just-in-time (JIT) compiler is used, the JIT compiler removes redundant null pointer check code via code analysis. This paper proposes a technique to remove additional null pointer check code that could not be removed by previous JIT compilation techniques, via early null pointer check using an architectural feature called predication. Generally, null point check code consists of two instructions: a compare and a branch. Our idea is moving the compare instruction that is usually located just before an use of an object, to the point right after the object is defined so that the total number of compare instructions is reduced. This results in reduction of dynamic and static compare instructions by 3.21$\%$ and 1.98$\%$. respectively, in SPECjvm98 bechmarks, compared to the code that has already been optimized by previous null pointer check elimination techniques. Its performance impact on an Itanium machine is an improvement of 0.32$\%$.