프로젝트 발할라는 자바의 시작 시점부터 플랫폼에 스며든 기술 부채를 해결하고자 하는 원대한 리팩터라고 할 수 있다. 이러한 발전은 자바가 고전적 언어에 그치지 않고 여전히 프로그래밍 언어 설계의 최전선에 있음을 입증한다. 프로젝트 발할라의 주요 기술적 구성요소와 발할라가 자바의 미래에 중요한 이유를 알아보자.
자바의 성능 문제
자바가 90년대에 처음 등장할 당시에는 모든 사용자 생성 형식은 클래스라고 결정됐고 소수의 프리미티브 형식만 특수한 경우로 취급됐다. 이는 포인터 기반 클래스 구조로 처리되는 것이 아니라 운영체제 형식에 직접 매핑됐다. 프리미티브 형식은 int, byte, short, long, float, double, boolean, char까지 총 8개다.객체의 참조 오버헤드가 없으면 수치 연산의 성능이 향상되므로 이러한 변수를 운영체제에 매핑하는 방식은 성능에 유리하게 작용했다. 또한 모든 데이터는 프로그램에서 궁극적으로 이 8개 프리미티브 형식 중 하나로 해석된다. 또 다른 종류의 구조는 배열이다. 프리미티브, 클래스, 배열이 자바의 광범위한 표현력을 구성하는 요소들이다.
그러나 프리미티브는 클래스 및 배열과는 전혀 다른 범주에 속한다. 프로그래머는 직관적으로 그 차이에 대처하도록 배웠다. 예를 들어 프리미티브는 값에 의한 전달(pass-by-value)인 반면 객체는 참조에 의한 전달(pass-by-reference)이다. 그 이유를 보려면 깊게 들어가야 한다. 결국은 동일성의 문제다. 프리미티브 값은 대체 가능하다고 말할 수 있다. int x = 4는 어느 곳에 나오든 정수 4다. equals()와 ==에서 그 차이를 볼 수 있다. 전자는 객체의 값 동등성(equivalence)을 테스트하고, 후자는 동일성(identity)을 테스트한다. 두 참조가 동일한 메모리 공간을 공유한다면 ==를 만족하고, 이는 둘이 동일한 객체임을 의미한다. 4로 설정된 모든 int 역시 ==를 만족하지만 int는 .equals()을 지원하지 않는다.
자바 가상 머신(JVM)은 프리미티브 처리 방법을 활용해서 프리미티브를 저장, 추출하고 프리미티브에 대해 작업을 수행하는 방식을 최적화할 수 있다. 특히 플랫폼에서 변수가 바뀌지 않는다고 판단하는 경우(즉, 상수이거나 불변성인 경우) 그 변수는 최적화할 수 있는 대상이 된다
반면 객체는 동일성이 있으므로 이러한 종류의 최적화에 저항한다. 객체는 클래스의 인스턴스로서 프리미티브일 수도 있고 다른 클래스일 수도 있는 데이터를 저장한다. 객체 자체는 포인터 핸들로 처리된다. 이렇게 해서 참조의 네트워크, 즉 객체 그래프가 형성된다. 값이 바뀔 때마다(또는 바뀌었을 가능성만 있는 경우에도) JVM은 참조를 위해 객체의 최종적인 레코드를 유지해야 한다. 객체 참조의 필요성은 일부 성능 최적화를 가로막는 장벽이다.
성능 측면의 난관은 여기에 그치지 않는다. 참조 버킷이라는 객체의 특성은 객체가 매우 부풀려진 방식으로 메모리에 존재함을 의미한다. 여기서 ‘부풀려진’이라는 표현은 JVM이 메모리 사용량을 최소화하기 위해 객체를 압축할 수 없다는 점을 묘사하기 위해 필자 개인적으로 사용하는 용어다. 한 객체에 구성의 일부로 다른 객체에 대한 참조가 있는 경우 JVM은 이 포인터 관계를 유지해야 한다. (잘 만들어진 최적화는 중첩된 참조가 특정 엔터티에 대한 유일한 핸들임을 확인하는 데 도움이 될 수도 있음)
고츠는 발할라 현황 블로그 글에서 포인트 배열을 사용해 참조의 조밀하지 않은 특성을 묘사한다. 우리는 클래스를 사용할 수 있다. 예를 들어 이름과 지리적 위치 필드가 있는 Landmark라는 클래스가 있다고 가정하자. 이는 다음과 같은 메모리 구조를 암시한다.
우리가 달성하고자 하는 목표는 그림 2와 같이 적절할 때 객체를 저장하는 기능이다.
이것이 초기 설계상의 결정에 의해 자바 플랫폼에 들어가게 된 성능 문제의 전반적인 개요다. 이제 이러한 의사 결정이 세 가지 주요 영역에서 어떻게 성능에 영향을 미치는지 생각해 보자.