Client Ahead-Of-Time Compiler for App-Downloading Systems

Abstract

어플리케이션(앱)을 다운로드 받아서 수행하는 시스템은 DTV나 스마트폰처럼 대중적으로 사용되고 있다. 앱을 다운받아서 사용하는 시스템들은 가상 머신을 주류로 사용하고 있다. 가상 머신의 가장 큰 문제점은 인터프리터를 통한 수행에 의한 느린 성능이며, 이 성능의 향상을 위해 주로 사용되는 기술이 적시 컴파일러이다. 적시 컴파일러는 다운받은 앱의 수행 중에 동적으로 머신 코드로 번역하여 사용하는 기법으로, 동적 컴파일레이션 오버헤드를 가지게 된다. 우리는 이 동적 컴파일레이션 오버헤드를 제거하여 성능을 향상시키는 클라이언트 선행 컴파일러를 제안하였다. 클라이언트 선행 컴파일러는 적시 컴파일러가 생성하는 머신 코드를 앱의 종료될 때 지우지 않고 파일형태로 스토리지에 저장하여 이후에 앱이 다시 수행될 때 저장한 머신 코드를 재활용하여 사용함으로써 런타임 컴파일레이션 오버헤드를 제거하게 된다. 저장한 머신 코드를 재활용할 때 머신 코드에 인코딩된 주소값들은 유효하지 않기 때문에 가상 머신의 현재 값에 맞추어 변경해주는 작업이 필요하다. 이 작업은 주소 재배치이다. 주소 재배치는 저장된 머신 코드만으로 수행할 수가 없기 때문에 추가적인 정보를 머신 코드를 저장하는 과정에서 생성하여 파일에 함께 저장해 주어야 한다. 자바의 상수 풀 해석은 주소 재배치 작업을 어렵게 한다. 우리는 이에 대한 해결책을 만들었다. 주소 재배치를 위한 정보들을 저장하기위해 영구 메모를 많이 사용하는 것도 문제가 된다. 따라서 우리는 주소 재배치 정보를 머신 코드 상에 인코딩하고 압축하여 저장하는 방법을 제안했다. 우리의 클라이언트 선행 컴파일러 기법은 오라클사의 CDC 가상머신 참조구현인 CVM에 구현하였다. 우리의 클라이언트 선행 컴파일러는 벤치마크의 성능을 약 12% 향상시켰다. 또한 우리는 클라이언트 선행 컴파일러 기법을 실제로 판매하는 DTV환경에 구축하여 실제 방송국이 사용하는 어플리케이션을 수행해 보았다. 우리의 클라이언트 선행 컴파일러 방식은 사용자의 실제 환경에서 33%의 좋은 성능 향상을 얻었다. 자바스크립트 가상머신인 구글사의 V8 가상머신은 인터프리터 수행없이 적시 컴파일러만을 사용하고 있다. 우리는 V8 가상 머신에 클라이언트 선행 컴파일러는 적용하였지만, 실제 성능 향상을 얻어내지는 못했다. 이것은 V8 가상 머신의 특징인 내부 객체의 적극적인 사용에 의한 결과이다. 내부 객체는 컴파일러가 생성하여 컴파일러 과정에서 사용되며, 자바스크립트 프로그램에서도 접근하여 사용하게 된다. V8 가상 머신의 컴포넌트들은 대부분 내부 객체로 생성되어, 다른 종류의 가상 머신에 비해서 상당히 많은 내부 객체를 생성하고 있다. V8의 적시 컴파일러가 생성하는 머신 코드에서는 이 내부 객체를 직접 접근하여 사용하게 되어, 클라이언트 선행 컴파일러에 의해 어플리케이션이 수행될 때마다 이 내부 객체는 항상 필요하기 때문에 클라이언트 선행 컴파일러는 내부 객체를 재생성해야만 한다. V8 적시 컴파일러의 런타임 컴파일레이션 오버헤드의 대부분이 내부 객체를 생성하는 오버헤드이기 때문에, 우리의 클라이언트 선행 컴파일러는 이 환경에서 충분한 성능 향상을 얻을 수 없었다.

App-downloading systems like DTV and smart phone are popularly used. Virtual machine is mainstream for those systems. One critical problem of app-downloading systems is performance because app is executed by interpreter. A popular solution for improving performance is Just-In-Time Compiler (JITC). JITC compiles to machine code at runtime. So, JITC suffers from runtime compilation overhead. We suggested client Ahead-Of-Time Compiler(c-AOTC) which improves the performance by removing runtime compilation overhead. c-AOTC saves machine code of method generated by JITC in persistent storage and reuses it in next runs. The machine code of a method translated by JITC is cached on a persistent memory of the device, and when the method is invoked again in a later run of the program, the machine code is loaded and executed directly without any translation overhead. One major issue in c-AOTC is relocation because some of the address constants embedded in the cached machine code are not correct when the machine code is loaded and used in a different run

those addresses should be corrected before they are used. Constant pool resolution complicates the relocation problem, and we propose our solutions. The persistent memory overhead for saving the relocation information is also an issue, and we propose a technique to encode the relocation information and compress the machine code efficiently. We developed a c-AOTC on Oracles CDC VM, and evaluation results indicate that c-AOTC can improve the performance as much as an average of 12% for benchmarks. And we adopted c-AOTC approach to commercial DTV platform and test the real xlet applications of commercial broadcasting stations. c-AOTC got average 33% performance improvement on the real xlet application test. V8 JavaScript VM does not use interpreter. Apps are executed only by JITC. We adopted c-AOTC to V8 VM. But we cannot get any good performance result because of V8 VMs characteristics. V8 VM components are generated as internal objects. Internal objects are used for compiling and running of JavaScript program. The machine code of V8 VM addresses internal objects which are different for each run. Because internal objects beaccessed in each run, c-AOTCmust recreate those objects. Because most of compilation overhead of V8 VM is internal object creation overhead, c-AOTCdoes not get enough improvements.