"도구" 태그로 연결된 5개 게시물개의 게시물이 있습니다.

이 블로그 게시물은 José Dapena Paz (Igalia)가 작성했으며, Jason Williams (Bloomberg), Ashley Claymore (Bloomberg), Rob Palmer (Bloomberg), Joyee Cheung (Igalia), Shu-yu Guo (Google)의 기여로 작성되었습니다.

이 게시물에서는 V8 힙 스냅샷과 관련된 Bloomberg 엔지니어들이 발견한 몇 가지 성능 문제와 이를 해결하여 JavaScript 메모리 분석을 그 어느 때보다 빠르게 만든 방법에 대해 설명합니다.

문제​

Bloomberg 엔지니어들은 JavaScript 애플리케이션에서 메모리 누수를 진단하려 하고 있었습니다. 이 애플리케이션은 메모리 부족(Out-Of-Memory) 오류로 실패하고 있었습니다. 테스트된 애플리케이션의 경우, V8 힙 한도가 약 1400 MB로 설정되어 있었습니다. 일반적으로 V8의 가비지 컬렉터는 힙 사용량을 이 한도 이하로 유지할 수 있어야 하므로 이러한 실패는 누수가 있을 가능성을 나타냅니다.

지난 3개월 동안 저는 V8 팀(Google London)에 인턴으로 합류하면서 많은 것을 배울 수 있는 멋진 경험을 가졌습니다. 그리고 새로운 도구인 Indicium를 개발하고 있었습니다.

이 시스템 분석기는 인라인 캐시(IC)와 Map이 실제 애플리케이션에서 어떻게 생성되고 수정되는지에 대한 패턴을 추적, 디버그 및 분석할 수 있는 통합 웹 인터페이스입니다.

V8은 이미 ICs와 Maps를 위한 추적 인프라를 가지고 있으며, IC Explorer 및 Map Processor를 사용하여 IC 이벤트 및 Map 이벤트를 처리하고 분석할 수 있습니다. 그러나 이전 도구들은 Map과 IC를 전체적으로 분석할 수 있는 기능이 부족했으며, 이제 시스템 분석기를 통해 이를 해결할 수 있습니다.

소개​

크롬과 엠스크립텐에서 최근 작업 덕분에, 이제 웹어셈블리 애플리케이션에서 최대 4GB의 메모리를 사용할 수 있습니다. 이전에는 2GB로 제한되었습니다. 왜 처음부터 제한이 있었는지 의아할 수 있습니다 - 예를 들어, 512MB 또는 1GB 메모리를 사용하는 데는 아무 작업이 필요하지 않았기 때문입니다! 하지만 브라우저와 툴체인에 있어서 2GB에서 4GB로의 도약에는 특별한 일이 발생한다고 밝혀졌습니다. 이 글에서는 그 내용을 설명하겠습니다.

우리는 .wasm 파일을 생성하거나 조작하는 컴파일러 및 기타 도구의 수가 점점 늘어나고 있으며, 때로는 그 안을 살펴보고 싶을 때가 있습니다. 아마도 당신은 그런 도구의 개발자이거나, 더 직접적으로는 Wasm을 대상으로 삼는 프로그래머로서 생성된 코드가 어떤 모습인지 성능이나 기타 이유로 궁금할 수 있습니다.

Emscripten은 항상 웹 및 Node.js와 같은 기타 JavaScript 환경에 컴파일하는 것을 최우선으로 고려해 왔습니다. 하지만 WebAssembly가 JavaScript 없이 사용되기 시작하면서 새로운 사용 사례가 등장하고, 우리는 Emscripten에서 독립형 Wasm 파일을 출력할 수 있는 지원을 개발해 왔습니다. 이는 Emscripten JS 런타임에 의존하지 않는 파일입니다. 이 게시물에서는 그 이유가 흥미로운 이유를 설명합니다.