본문으로 건너뛰기

"internals" 태그로 연결된 34개 게시물개의 게시물이 있습니다.

모든 태그 보기

육지 발견: 노드의 바다를 떠나며

· 약 24분
다리우스 메르카디에

V8의 최종 단계 최적화 컴파일러인 Turbofan은 대규모 생산 컴파일러 중에서 드물게 Sea of Nodes (SoN)을 사용하는 것으로 유명합니다. 그러나 약 3년 전부터 우리는 Sea of Nodes를 제거하고 더 전통적인 Control-Flow Graph (CFG) Intermediate Representation (IR)로 되돌아가기 시작했습니다. 이 새로운 IR을 우리는 Turboshaft라고 명명했습니다. 현재 Turbofan의 JavaScript 백엔드는 전부 Turboshaft를 사용하고 있으며, WebAssembly 파이프라인 전체에서도 Turboshaft를 사용하고 있습니다. Turbofan의 두 부분은 여전히 Sea of Nodes를 일부 사용하는데, 하나는 내장 파이프라인이며, 이를 천천히 Turboshaft로 교체하고 있으며, 다른 하나는 JavaScript 파이프라인의 프론트엔드로 이는 또 다른 CFG 기반 IR인 Maglev로 교체 중입니다. 이 블로그 글에서는 우리가 Sea of Nodes를 벗어나기로 한 이유를 설명합니다.

Oilpan에서의 포인터 압축

· 약 12분
Anton Bikineev와 Michael Lippautz ([@mlippautz](https://twitter.com/mlippautz)), walking disassemblers

프로그램이 4GB 미만의 RAM을 사용하는 경우 64비트 포인터를 사용하는 것은 절대적으로 터무니없습니다. 그러한 포인터 값이 구조체 안에 나타난다면, 이는 메모리를 절반 이상 낭비할 뿐만 아니라 캐시의 절반을 효과적으로 버리는 셈입니다.

Donald Knuth (2008)

Oilpan 라이브러리

· 약 6분
Anton Bikineev, Omer Katz ([@omerktz](https://twitter.com/omerktz)), Michael Lippautz ([@mlippautz](https://twitter.com/mlippautz)) - 효율적이고 효과적인 파일 이동자

이 글의 제목이 오일팬 관련 책 모음을 깊이 탐구하자는 의미로 보일 수 있으나(오일팬을 위한 구조적 기준을 생각하면 놀라울 정도로 많은 문헌이 이에 대해 다룹니다), 우리는 V8 v9.4부터 라이브러리로 호스팅되고 있는 C++ 가비지 컬렉터인 Oilpan에 대해 좀 더 자세히 살펴보려고 합니다.

더 빠른 JavaScript 호출

· 약 15분
[Victor Gomes](https://twitter.com/VictorBFG), 프레임 제거기

JavaScript는 함수 호출 시 기대되는 매개변수의 수와 다른 수의 인수를 전달할 수 있도록 허용합니다. 즉, 선언된 형식 매개변수보다 적거나 많은 인수를 전달할 수 있습니다. 앞의 경우를 언더 어플리케이션(under-application), 뒤의 경우를 오버 어플리케이션(over-application)이라고 합니다.

C++를 위한 고성능 가비지 컬렉션

· 약 8분
Anton Bikineev, Omer Katz ([@omerktz](https://twitter.com/omerktz)), 그리고 Michael Lippautz ([@mlippautz](https://twitter.com/mlippautz)), C++ 메모리 전문가

과거에는 이미 여러 번 게시물에 JavaScript의 가비지 컬렉션, 문서 객체 모델(DOM), 그리고 이것이 V8에서 구현되고 최적화되는 방식에 대해 작성한 적이 있습니다. 하지만 Chromium의 모든 요소가 JavaScript로 작성된 것은 아닙니다. 대부분의 브라우저와 V8이 내장된 Blink 렌더링 엔진은 C++로 작성되었습니다. JavaScript는 DOM과 상호 작용할 수 있으며, 이는 이후 렌더링 파이프라인에 의해 처리됩니다.

V8 정규 표현식 개선

· 약 5분
정규 표현식에 대한 의견을 자주 표현하는 Patrick Thier와 Ana Peško

기본 설정에서 V8은 정규 표현식을 처음 실행할 때 네이티브 코드로 컴파일합니다. JIT-less V8 작업의 일부로 우리는 정규 표현식을 위한 인터프리터를 도입했습니다. 정규 표현식을 해석하면 더 적은 메모리를 사용하는 장점이 있지만, 성능 상의 단점도 동반됩니다. 이 블로그 게시물에서는 정규 표현식을 해석하는 장점을 활용하고 단점을 완화하는 방법을 설명합니다.

더 가벼운 V8

· 약 9분
Mythri Alle, Dan Elphick, 그리고 [Ross McIlroy](https://twitter.com/rossmcilroy), V8 웨이트워처

2018년 말, 우리는 V8의 메모리 사용량을 대폭 줄이기 위한 V8 Lite라는 프로젝트를 시작했습니다. 처음에 이 프로젝트는 메모리 사용량 감소가 실행 속도보다 중요한 저메모리 모바일 기기나 임베디드 사용 사례에 특화된 Lite 모드라는 독립적인 형태로 구상되었습니다. 하지만 작업을 진행하면서, 이 Lite 모드를 위해 적용된 많은 메모리 최적화 방법이 일반 V8에서도 사용할 수 있어 V8의 모든 사용자에게 이점을 줄 수 있다는 것을 깨달았습니다.

React에서의 V8 성능 저하 이야기

· 약 15분
Benedikt Meurer ([@bmeurer](https://twitter.com/bmeurer)) 및 Mathias Bynens ([@mathias](https://twitter.com/mathias))

이전에는 Shapes와 Inline Caches를 사용하여 JavaScript 엔진이 객체 및 배열 접근을 최적화하는 방식을 논의했고, 프로토타입 속성 접근 속도를 높이는 방법을 탐구했습니다. 이번 글에서는 V8이 다양한 JavaScript 값을 메모리에 최적으로 표현하는 방식을 설명하며, Shape 기계에 어떤 영향을 미치는지 — 이러한 모든 내용은 React 핵심에서 발생한 최근 V8 성능 저하를 이해하는 데 도움이 됩니다.

2019년 JavaScript 비용

· 약 11분
Addy Osmani ([@addyosmani](https://twitter.com/addyosmani)), JavaScript 정리자, Mathias Bynens ([@mathias](https://twitter.com/mathias)), 메인 스레드 해방자
노트

참고: 기사를 읽는 것보다 프레젠테이션을 보는 것을 선호한다면, 아래 영상을 즐겨보세요! 그렇지 않다면, 영상을 건너뛰고 읽어주세요.

“JavaScript 비용” - Addy Osmani가 #PerfMatters Conference 2019에서 발표.