Я никогда глубоко не работала с бинарными данными в JavaScript. Какое-то время назад стало интересно, что же там есть, как оно работает и для чего используется. Дальше в нескольких постах будет мой микроконспект, а также некоторые интересные нюансы работы "под капотом".
ArrayBuffer — это основа всего, просто кусок сырой памяти. Однако работать с ним напрямую нельзя. Для этого существуют TypedArray. Это набор вьюшек поверх ArrayBuffer с конкретной интерпретацией байтов, например:
const buf = new ArrayBuffer(16);
const i32 = new Int32Array(buf); // 4 элемента по 4 байта
const u8 = new Uint8Array(buf); // 16 элементов по 1 байту
Здесь команда new ArrayBuffer(16) выделяет непрерывную область памяти размером 16 байт и заполняет её нулями, а обе вьюшки смотрят на одну и ту же память.
Доступных вьюшек много, вот они: Int8Array, Uint8Array, Uint8ClampedArray, Int16Array, Uint16Array, Int32Array, Uint32Array, Float32Array, Float64Array, BigInt64Array, BigUint64Array. По факту все они позволяют отобразить выделенную память в числа разного диапазона и количества байт.
Есть ещё DataView, который позволяет читать разные типы с произвольных смещений:
let dataView = new DataView(buf);
dataView.getUint8(0); // получим 8-битное число на позиции 0
dataView.getUint32(0) // получим 32-битное число на позиции 0
dataView.setUint32(0, 0); // установим 4-байтового числа в 0 на позиции 0
Что происходит под капотом? Из интересного, сырые байты ArrayBuffer, если он больше 64 байт, V8 хранит за пределами кучи. Давайте разберём этот механизм подробнее.
Когда вы создаёте new ArrayBuffer(1024), V8 внутри себя создаёт два объекта:
1. JS-объект ArrayBuffer — живёт в куче, участвует в сборке мусора
2. BackingStore — обёртка вокруг указателя на реальный блок памяти
BackingStore знает три вещи: указатель на данные, размер и как эту память освободить. Когда ArrayBuffer собирается GC, BackingStore вызывает деаллокатор внутри V8.
Для маленьких ArrayBuffer (≤ 64 байт) V8 может хранить данные прямо внутри JS-объекта в куче. BackingStore как структура формально существует, но отдельной аллокации памяти за ним нет.
С одной стороны, если бы ArrayBuffer всегда лежал внутри кучи, то память быстрее бы аллоцировалась. Однако V8 не держит большие буфферы там, потому что для использования в postMessage(arrayBuffer) разработчики ожидают zero-copy передачу, которую нельзя позволить из соображений безопасности, если ArrayBuffer хранится в куче. Обсуждение этого можно почитать тут.
И ещё один факт, если вы помните про ElementKinds из моей статьи про V8, то там мы разбирали базовые типы элементов, которые используются чаще всего.
Однако для TypedArray у движка есть отдельные ElementKinds, причём каждый тип (Int8Array, Float64Array и т.д.) — это отдельный ElementKinds. Всё потому, что для TypedArray тип всегда зафиксирован при создании, в то время как для обычных массивов типы могут меняться в рантайме.
ArrayBuffer — это основа всего, просто кусок сырой памяти. Однако работать с ним напрямую нельзя. Для этого существуют TypedArray. Это набор вьюшек поверх ArrayBuffer с конкретной интерпретацией байтов, например:
const buf = new ArrayBuffer(16);
const i32 = new Int32Array(buf); // 4 элемента по 4 байта
const u8 = new Uint8Array(buf); // 16 элементов по 1 байту
Здесь команда new ArrayBuffer(16) выделяет непрерывную область памяти размером 16 байт и заполняет её нулями, а обе вьюшки смотрят на одну и ту же память.
Доступных вьюшек много, вот они: Int8Array, Uint8Array, Uint8ClampedArray, Int16Array, Uint16Array, Int32Array, Uint32Array, Float32Array, Float64Array, BigInt64Array, BigUint64Array. По факту все они позволяют отобразить выделенную память в числа разного диапазона и количества байт.
Есть ещё DataView, который позволяет читать разные типы с произвольных смещений:
let dataView = new DataView(buf);
dataView.getUint8(0); // получим 8-битное число на позиции 0
dataView.getUint32(0) // получим 32-битное число на позиции 0
dataView.setUint32(0, 0); // установим 4-байтового числа в 0 на позиции 0
Что происходит под капотом? Из интересного, сырые байты ArrayBuffer, если он больше 64 байт, V8 хранит за пределами кучи. Давайте разберём этот механизм подробнее.
Когда вы создаёте new ArrayBuffer(1024), V8 внутри себя создаёт два объекта:
1. JS-объект ArrayBuffer — живёт в куче, участвует в сборке мусора
2. BackingStore — обёртка вокруг указателя на реальный блок памяти
BackingStore знает три вещи: указатель на данные, размер и как эту память освободить. Когда ArrayBuffer собирается GC, BackingStore вызывает деаллокатор внутри V8.
Для маленьких ArrayBuffer (≤ 64 байт) V8 может хранить данные прямо внутри JS-объекта в куче. BackingStore как структура формально существует, но отдельной аллокации памяти за ним нет.
С одной стороны, если бы ArrayBuffer всегда лежал внутри кучи, то память быстрее бы аллоцировалась. Однако V8 не держит большие буфферы там, потому что для использования в postMessage(arrayBuffer) разработчики ожидают zero-copy передачу, которую нельзя позволить из соображений безопасности, если ArrayBuffer хранится в куче. Обсуждение этого можно почитать тут.
И ещё один факт, если вы помните про ElementKinds из моей статьи про V8, то там мы разбирали базовые типы элементов, которые используются чаще всего.
Elements Kinds — внутренние категории V8, определяющие, как именно хранятся элементы массива в памяти и как к ним обращаться.
Однако для TypedArray у движка есть отдельные ElementKinds, причём каждый тип (Int8Array, Float64Array и т.д.) — это отдельный ElementKinds. Всё потому, что для TypedArray тип всегда зафиксирован при создании, в то время как для обычных массивов типы могут меняться в рантайме.