asm.js에 작별을 고하기

• Firefox 148부터 SpiderMonkey의 asm.js 최적화가 기본 비활성화됐고, 향후 관련 코드가 제거될 예정
• asm.js는 JavaScript 하위 집합이라 기존 사이트는 계속 동작하지만, 일반 JIT 경로로 실행되어 최적화 이점은 사라짐
• asm.js 콘텐츠는 WebAssembly로 다시 컴파일하면 더 빠른 실행과 더 작은 바이너리를 얻을 수 있음
• asm.js는 NaCl·PNaCl에 맞서 별도 샌드박스나 대체 API 없이 웹 콘텐츠 안에서 네이티브에 가까운 실행을 가능하게 함
• 2013년 Firefox 22에 들어간 OdinMonkey는 Unity·Unreal 같은 C/C++ 웹 배포를 가능하게 했고, WebAssembly로 이어지는 기반이 됨

asm.js 최적화 비활성화

• Firefox 148부터 SpiderMonkey의 asm.js 최적화가 기본 비활성화됐고, 향후 릴리스에서 관련 코드 전체가 제거될 예정
• asm.js를 쓰는 사이트는 계속 동작함
  • asm.js는 일반 JavaScript의 하위 집합이어서 기존 코드는 다른 스크립트처럼 일반 JIT 경로로 실행됨
  • 다만 asm.js 전용 최적화 이점은 사라짐
• asm.js 콘텐츠를 계속 배포 중이라면 WebAssembly로 다시 컴파일하는 것이 권장됨
  • WebAssembly로 다시 컴파일하면 더 빠른 실행과 더 작은 바이너리를 얻을 수 있음
  • SpiderMonkey의 WebAssembly 파이프라인은 asm.js 파이프라인보다 훨씬 더 발전해 있음
• WebAssembly가 성공했고 asm.js 사용량 대부분이 이미 이전되면서 두 경로를 함께 유지하는 비용이 커짐
  • 유지보수 시간이 계속 필요함
  • VM 안에 추가 공격 표면이 남음

asm.js의 역할과 OdinMonkey의 종료

• asm.js는 NaCl과 PNaCl이 던진 “웹에서 네이티브 속도로 코드를 실행할 수 있는가”라는 질문에 대한 Mozilla의 답이었음
  • 엔진이 즉석에서 인식할 수 있는 엄격하고 정적으로 타입이 지정된 JavaScript 하위 집합을 골라 네이티브 코드로 컴파일하는 방식
  • 별도 샌드박스, IPC, 대체 API 없이 웹 콘텐츠 안에 머물면서 기존 웹 API를 사용할 수 있었음
• asm.js는 2013년 Firefox 22에 포함됐고, Unity와 Unreal 같은 프로젝트가 표준 웹 기술만으로 C/C++ 코드베이스를 웹에 배포할 수 있게 해줌
  • Epic Citadel demo는 4일 만에 웹으로 포팅됨
  • asm.js는 웹 기술만으로 거의 네이티브에 가까운 속도의 코드를 실행할 수 있음을 입증했고, 이후 WebAssembly로 이어지는 길을 열었음
  • WebAssembly는 몇 년 뒤 Firefox 52에 포함됐으며, asm.js가 없었다면 WebAssembly도 없었을 가능성이 큼
• asm.js 컴파일러의 이름은 OdinMonkey였고, 제거 작업은 Ragnarök 버그에서 “Twilight of OdinMonkey”로 추적됨
  • OdinMonkey에서 태어난 BaldrMonkey는 WebAssembly 최적화 컴파일러
  • RabaldrMonkey는 WebAssembly 베이스라인 컴파일러
  • OdinMonkey는 13년간의 역할을 마치고 종료 수순에 들어감