2008년 8월, Mozilla는 TraceMonkey를 소개 했습니다. 우리가 Firefox 3.5에 탑재한 이 새로운 엔진은 차세대 Web 브라우저와 Web 응용 프로그램을 구축하는데 있어서 성능의 새시대를 예고 하는 것 이였습니다. 우리가 새로운 엔진을 공개한 뒤, Google은 V8을 가진 Chrome을 발표했습니다. Apple 또한, Safari에 자체 엔진을 도입했고, Opera도 최신 베타 버전 브라우저에 새로운 엔진을 탑재하고 있습니다.

이러한 새로운 엔진의 직접적인 결과로 우리는 새로운 종류의 응용 프로그램이 등장하는 것을 목격하게됩니다. Processing을 Web으로 가져온 사람도 있고, 실시간 오디오 편집 및 게임등 기타 여러 가지를 실험 합니다. (그 외 Canvas 데모 목록에 소개한 좋은 예제들도 참조하세요.)

이러한 새로운 응용 프로그램과 우리의 JavaScript 엔진의 상호 작용에 대해 우리는 Mozilla에서 2가지를 배웠습니다.

1. 이러한 Tracing에 의한 접근 방식은 코드의 특정 스타일과 상호작용이 나쁘게 되는 경향이 있다. (위에 예를 들은 NES 게임은 우리 엔진에서 매우 나쁘게 작동하는 경향이 있다. – 그것은 본질적으로 커다란 switch 문입니다.)
2. 우리가 “Trace에 존재”(아래 참조) 할 수 있을 때, TraceMonkey는 다른 모든 엔진에 이기고 있다.

Mozilla의 엔진은 다른 엔진과는 근본적으로 다릅니다. 다른 엔진들은 모두 “메소드 기반 JIT”이라고 하는 것을 사용합니다. 그것은 읽어들인 모든 JS 코드를 기계어로 컴파일하고 실행합니다. Firefox는 “tracing JIT”을 사용합니다. 우리는 읽어들인 모든 JS 코드를 해석하고 인터프리터에서 실행하면서 기록합니다. 핫 경로를 발견하면, 그것을 기계어로 변환하고 내부적으로 실행 합니다. (Tracing 대한 자세한 내용은 지난해 hacks의 포스트를 참조하세요.)

Tracing JIT 의 단점이라고 한다면, 특정 조건에 도달하면 언제든 인터프리터와 기계어를 서로 바꿔가며 실행 해야 한다는 것 입니다. 기계어에서 인터프리터로 돌려 보내야 할 경우를 “Trace가 중단됐다” 라고 부릅니다. 물론 인터프리터는 원시 기계어로 실행되는 것에 비해 더 느리며, 예상한것 이상으로 더 많은 일이 발생합니다.

그래서 우리는 2세대 엔진에 두 방법의 좋은 요소를 결합하기로 했습니다.

1. 우리는 WebKit JS 엔진의 일부를 사용하고 JavaScript 코드를 실행하도록 완전한 메소드 JIT을 빌드 합니다. 이것은 다른 엔진과 같은 수준의 성능을 낼 수 있게 합니다. 그리고 가장 중요한 것은 일관성이 유지 됩니다. 즉, 더 이상 trace를 인터프리터 코드로 변경하면서 커다란 시간 낭비를 하지 않게 된다는 뜻입니다.
2. 기계어 내부의 루프에서 더 빠른 코드로 변환하기 위해 Tracing 엔진을 결합 할 것 입니다. 이 말은, 우리가 여전히 메소드 기반 JIT의 일관성을 유지하면서 Tracing 엔진의 강점 살릴 수 있다는 의미 입니다.

이 작업은 여전히 아주 초기 단계이며, 데모를 보여줄 수 있는 단계는 아니지만, 사람들에게 우리가 무엇을 하려고 하는지 이해해 주길 바라는 마음에 포스팅 하기로 생각 했습니다.

더 자세한 정보를 원하시는 분은 David Mandelin과 David Anderson의 블로그와 새로운 엔진 프로젝트 페이지를 참조하세요.

원저자: Christoper Blizzard – 원문으로 가기