"내부 구조" 태그로 연결된 8개 게시물개의 게시물이 있습니다.

슬랙 추적은 새로운 객체에 실제로 사용하는 것보다 더 큰 초기 크기를 부여하여 새로운 속성을 빠르게 추가할 수 있도록 합니다. 그런 다음 일정 시간이 지나면 사용하지 않은 공간을 시스템으로 마법같이 반환하는 방식입니다. 멋지지 않나요?

메모리와 성능 사이에는 항상 끊임없는 싸움이 있습니다. 사용자로서 우리는 빠르면서도 가능한 적은 메모리를 소비하기를 원합니다. 불행히도 일반적으로 성능을 향상시키면 메모리 소비가 증가하고 (그 반대도 마찬가지입니다).

JavaScript 프로그램을 실행하려면 V8이 이를 이해할 수 있도록 소스 텍스트를 처리해야 합니다. V8은 먼저 소스를 추상 구문 트리(AST)로 파싱합니다. AST는 프로그램 구조를 나타내는 객체 집합입니다. Ignition이 이 AST를 바이트 코드로 컴파일합니다. 이러한 파싱 + 컴파일 단계의 성능은 중요합니다. 컴파일이 완료되기 전에 V8은 코드를 실행할 수 없습니다. 이 블로그 게시물 시리즈에서는 파싱과 V8에서 초고속 파서를 제공하기 위해 수행한 작업에 대해 집중적으로 다룹니다.

지난 몇 년 동안 V8 가비지 컬렉터(GC)는 많은 변화를 겪었습니다. 오리노코 프로젝트는 순차적으로 중단되는 가비지 컬렉터를 대부분 병렬적이고 동시적으로 실행 가능한 컬렉터로 변환시켰으며, 점진적 대체 방식도 포함했습니다.

V8 내장 함수(빌트인 함수)는 V8의 모든 인스턴스에서 메모리를 소비합니다. 빌트인 함수의 개수, 평균 크기, 그리고 크롬 브라우저 탭당 V8 인스턴스 수는 크게 증가해 왔습니다. 이 블로그 게시물에서는 지난 1년 동안 웹사이트당 평균 V8 힙 크기를 19% 줄이는 방법을 설명합니다.

프록시는 ES2015 이래 JavaScript에서 중요한 부분이었습니다. 이들은 객체에 대해 근본적인 작업을 가로채고 동작을 사용자 정의할 수 있게 해줍니다. 프록시는 jsdom 및 Comlink RPC 라이브러리와 같은 프로젝트의 핵심 부분을 형성합니다. 최근에 우리는 V8에서 프록시 성능을 개선하기 위해 많은 노력을 기울였습니다. 이 글은 V8에서의 일반적인 성능 개선 패턴과 특히 프록시에 대해 설명합니다.

약 3개월 전에 저는 V8 팀 (구글 뮌헨)에서 인턴으로 합류했으며, 그 이후로 VM의 _Deoptimizer_라는 완전히 새로운 프로젝트에 대해 작업하고 있습니다. 이는 매우 흥미롭고 도전적인 프로젝트임을 입증했습니다. 제 인턴십 첫 번째 부분은 VM의 보안성을 개선하는 데 초점을 맞췄습니다. 두 번째 부분은 성능 개선에 중점을 두었습니다. 즉, 이전에 비최적화된 함수를 언링크할 때 사용된 데이터 구조를 제거하는 작업을 수행했으며, 이는 쓰레기 수집 중 성능 병목현상을 일으킨 문제였습니다. 이 블로그 게시물은 제 인턴십의 두 번째 부분에 대해 설명하며, V8이 비최적화된 함수들을 어떻게 언링크했는지, 이를 어떻게 변경했는지, 그리고 얻은 성능 향상에 대해 설명합니다.

JavaScript 명세에는 수학 함수에서부터 정규 표현식 엔진에 이르기까지 많은 내장 기능이 포함되어 있습니다. 새로 생성된 V8 컨텍스트는 시작 시 이러한 기능들을 사용할 수 있습니다. 이를 위해, 전역 객체(브라우저의 경우 window 객체 등)와 모든 내장 기능이 V8 힙에 설정되고 초기화되어야 합니다. 이 작업을 처음부터 수행하려면 시간이 꽤 걸립니다.