Memory Inspector 소개

Kim-Anh Tran
Kim-Anh Tran

이 도움말에서는 Chrome 91에 출시된 메모리 검사기를 소개합니다. 이를 통해 ArrayBuffer, TypedArray, DataView, Wasm 메모리를 검사할 수 있습니다.

소개

ArrayBuffer에 있는 데이터의 의미를 알고 싶었던 적이 있으세요? Memory Inspector가 출시되기 전에는 DevTools에서 ArrayBuffers에 대한 제한적인 통계만 허용했습니다. 디버깅 세션 중 Scope 뷰에서 검사하는 작업이 배열 버퍼 내의 단일 값 목록 보기로 제한되어 데이터 전체를 이해하기가 어려웠습니다. 예를 들어 아래 예에서 Scope 뷰에는 버퍼가 배열의 확장 가능한 범위로 표시됩니다.

DevTools의 범위 뷰

버퍼 내의 특정 범위로 이동하는 것은 번거로웠고 사용자가 최종적으로 해당 색인에 도달하기 위해 아래로 스크롤해야 했습니다. 하지만 위치로 이동하는 것이 쉬울지라도 실제로 값을 inspecting하는 방법은 번거롭습니다. 이 숫자가 무엇을 의미하는지 파악하기 어렵습니다. 특히 단일 바이트가 아니라 32비트 정수로 해석해서는 안 된다면 어떻게 될까요?

메모리 검사기를 사용하여 값 검사

메모리 검사기

Chrome 91에서는 배열 버퍼를 검사하는 도구인 Memory Inspector를 소개합니다. 앞서 살펴본 메모리 검사 도구는 바이너리 데이터를 그 주소와 함께 그리드에 표시하고 기본 값을 해석하는 다양한 방법을 제공합니다. Memory Inspector에서 제공하는 기능입니다. 이제 Memory Inspector를 사용하여 콘텐츠를 보고 탐색하고 현재 값을 해석하는 데 사용할 유형을 선택할 수 있습니다. 바이트 바로 옆에 ASCII 값이 표시되며 사용자가 다른 엔디언을 선택할 수 있습니다. 아래의 실제 메모리 검사기를 참고하세요.

이용해 보시겠습니까? Memory Inspector를 열고 배열 버퍼 (또는 TypedArray, DataView 또는 Wasm Memory)를 확인하는 방법과 사용 방법을 자세히 알아보려면 메모리 검사기에 관한 문서를 참고하세요. 장난감 예시 (JS, Wasm, C++용)를 사용해 보세요.

메모리 검사기 디자인

이 파트에서는 웹 구성요소를 사용하여 메모리 검사기를 어떻게 설계했는지 살펴보고, 설계 목표 중 하나, 그리고 이를 어떻게 구현했는지 살펴보겠습니다. 궁금한 점이 있거나 자세한 내용을 알아보려면 Memory Inspector에 관한 디자인 문서를 참고하세요.

웹 구성요소로 이전에 관한 블로그 게시물을 보셨을 것입니다. 잭은 웹 구성요소를 사용하여 UI 구성요소를 빌드하는 방법에 관한 내부 가이드를 게시했습니다. 웹 구성요소로의 이전은 Memory Inspector에 대한 작업과 동시에 진행되어 새로운 시스템을 사용해 보기로 결정했습니다. 다음은 Memory Inspector를 만들기 위해 빌드한 구성요소를 보여주는 다이어그램입니다 (내부적으로는 Linear Memory Inspector라고 함).

웹 구성요소

LinearMemoryInspector 구성요소는 메모리 검사기의 모든 요소를 빌드하는 하위 구성요소를 결합하는 상위 구성요소입니다. 기본적으로 Uint8Arrayaddress를 사용하고 둘 중 하나가 변경될 때마다 데이터를 하위 요소에 전파하여 재렌더링을 트리거합니다. LinearMemoryInspector 자체는 다음 세 가지 하위 구성요소를 렌더링합니다.

  1. LinearMemoryViewer (값 표시),
  2. LinearMemoryNavigator (탐색 허용)
  3. LinearMemoryValueInterpreter (기본 데이터의 다양한 유형 해석 표시)

후자는 그 자체가 상위 구성요소로, ValueInterpreterDisplay (값 표시)와 ValueInterpreterSettings (디스플레이에 표시할 유형 선택)을 렌더링합니다.

각 구성요소는 필요한 경우 구성요소를 재사용할 수 있도록 UI의 작은 구성요소 하나만 나타내도록 설계되었습니다. 구성요소에 새 데이터가 설정될 때마다 다시 렌더링이 트리거되어 구성요소에 설정된 데이터에 반영된 변경사항이 표시됩니다. 구성요소가 포함된 워크플로의 한 예는 아래에 나와 있습니다. 여기서는 사용자가 주소 표시줄에서 주소를 변경하면 새 데이터(이 경우 확인할 주소)를 설정하여 업데이트를 트리거합니다.

구성요소 다이어그램

LinearMemoryInspectorLinearMemoryNavigator에 리스너로 자신을 추가합니다. addressChanged 함수는 address-changed 이벤트에서 트리거됩니다. 이제 사용자가 주소 입력을 수정하는 즉시 앞서 언급한 이벤트가 전송되어 addressChanged 함수가 호출됩니다. 이제 이 함수는 주소를 내부적으로 저장하고 data(address, ..) setter를 사용하여 하위 구성요소를 업데이트합니다. 하위 구성요소는 주소를 내부적으로 저장하고 뷰를 다시 렌더링하여 이 특정 주소에 콘텐츠를 표시합니다.

설계 목표: 버퍼 크기와 무관하게 성능 및 메모리 소비를 지원

Memory Inspector를 설계할 때 염두에 두었던 한 가지 측면은 Memory Inspector의 성능이 버퍼 크기와 독립적이어야 한다는 것입니다.

이전 부분에서 살펴본 것처럼 LinearMemoryInspector 구성요소는 UInt8Array를 사용하여 값을 렌더링합니다. 동시에 메모리 검사기는 일부 데이터만 표시하므로 Memory Inspector가 전체 데이터를 보관할 필요가 없도록 해야 했습니다 (예: Wasm 메모리는 최대 4GB이며 Memory Inspector에는 4GB는 저장하지 않으려고 함).

따라서 Memory Inspector의 속도와 메모리 소비가 표시된 실제 버퍼와 관계가 없도록 하기 위해 LinearMemoryInspector 구성요소가 원래 버퍼의 하위 범위만 유지하도록 합니다.

이 기능이 작동하려면 LinearMemoryInspector가 먼저 memoryOffsetouterMemoryLength라는 두 개의 인수를 더 사용해야 합니다. memoryOffset전달된 Uint8Array가 시작되는 오프셋을 나타내며 올바른 데이터 주소를 렌더링하는 데 필요합니다. outerMemoryLength는 원래 버퍼의 길이이며, 표시할 수 있는 범위를 파악하는 데 필요합니다.

buffer

이 정보를 사용하면 실제로 모든 데이터를 제자리에 두지 않고도 이전과 동일한 뷰 (address 주변 콘텐츠)를 계속 렌더링할 수 있습니다. 그렇다면 다른 범위에 속하는 다른 주소가 요청되면 어떻게 해야 할까요? 이 경우 LinearMemoryInspector는 유지되는 현재 범위를 업데이트하는 RequestMemoryEvent를 트리거합니다. 아래 예를 참고하세요.

이벤트 트리거 흐름 다이어그램

이 예에서는 사용자가 메모리 페이지를 탐색하여 (메모리 검사기는 데이터 청크를 표시하기 위해 페이징을 사용) RequestMemoryEvent를 트리거하는 PageNavigationEvent를 트리거합니다. 이 이벤트는 새 범위를 가져오기 시작하여 데이터 설정을 통해 LinearMemoryInspector 구성요소로 전파됩니다. 따라서 새로 가져온 데이터가 표시됩니다.

아, 알고 계셨나요? Wasm 및 C/C++ 코드에서도 메모리를 검사할 수 있습니다.

Memory Inspector는 JavaScript의 ArrayBuffers에 사용할 수 있을 뿐만 아니라 DWARF 확장 프로그램을 사용하여 Wasm 메모리와 C/C++ 참조/포인터가 가리키는 메모리를 검사하는 데도 사용할 수 있습니다. 아직 사용해 보지 않았다면 한번 사용해 보세요. 최신 도구로 WebAssembly 디버깅을 참고하세요. 웹에서 C++의 네이티브 디버깅을 실행하는 Memory Inspector에 대한 간단한 개요:

C++에서 메모리 검사

결론

이 도움말에서는 Memory Inspector를 소개하고 디자인을 간단히 보여주었습니다. Memory Inspector가 ArrayBuffer에서 발생하는 상황을 이해하는 데 도움이 되기를 바랍니다. 개선을 위한 제안사항이 있으면 Google에 알려주시고 버그를 신고해 주세요.

미리보기 채널 다운로드

Chrome Canary, 개발자 또는 베타를 기본 개발 브라우저로 사용하는 것이 좋습니다. 이러한 Preview 채널을 통해 개발자는 최신 DevTools 기능에 액세스하고 최첨단 웹 플랫폼 API를 테스트하며 다른 사용자보다 먼저 사이트에서 문제를 찾을 수 있습니다.

Chrome DevTools팀에 문의하기

게시물에서 새로운 기능과 변경사항 또는 DevTools와 관련된 다른 항목에 대해 논의하려면 다음 옵션을 사용하세요.

  • crbug.com을 통해 제안 또는 의견을 제출하세요.
  • DevTools에서 옵션 더보기   더보기   > 도움말 > DevTools 문제 신고를 사용하여 DevTools 문제를 신고합니다.
  • @ChromeDevTools로 트윗을 보냅니다.
  • DevTools의 새로운 기능 YouTube 동영상 또는 DevTools 팁 YouTube 동영상에 댓글을 남겨주세요.