Это, я думаю, не про массивы. Речь идёт о жабаскрипте, а не о C. js отличается динамической типизацией и сборкой мусора. js на уровне синтаксиса не различает объект и указатель на объект. Это значит, например, что в нём невозможно создать вещь типа:(1)
struct Container {
struct Contained inner;
}
Можно лишь что-то вроде:
struct Container {
struct Referenced *inner;
}
(2)
Если же вернутся к динамической типизации и сборке мусора, то эти вещи нагружают указатели новыми смыслами и функциями, которыми не обладают C'шные указатели. Промежь битов указателя может быть запрятан бит сборщика мусора, может быть ещё несколько бит тега типа (это помогает работать с некоторыми примитивными типами без ссылок -- если int сузить с 32 бит, до 28, то в освободившиеся 4 бита можно впихнуть бит сборщика мусора и 3 бита тега типа, по которому можно отличить в рантайме указатель от int'а, в elisp, например, так и сделано).
И здесь возникает ещё одна интересность: если переменная не имеет типа, значит она может содержать в себе любой объект, то есть она может содержать в себе указатель, а значит под переменную надо выделять место как под указатель. Нам нужен массив восьмибитных интов, но вместо него мы выделяем массив 64-х битных интов. С этим можно бороться реализуя тип "массив восьмибитных интов" на уровне интерпретатора/виртуальной машины, но такие штуки всё равно приводят к проблемам, например если нам хочется передать в какую-нибудь функцию указатель на такой int из массива куда-нибудь, то что делать? Создавать дескриптор типа (указатель на упакованный/невыровненный u8), создавать объект этого типа, который будет содержать в себе указатель на дескриптор (ради типизационного динамизма) и указатель на u8, и передавать в функцию указатель на этот объект?
Я не знаю, как там сделано в V8, но суть в том, что попытки спрятать от программиста различие между указателем и объектом в любом случае приводят к увеличению количества указателей.
(3)
Но js в браузере при этом работает не с произвольными структурами, а со структурами, описывающими html, то есть составленными из многих нодов со многими перекрёстными ссылками между ними. Если включить фантазию и подумать, как можно html тег представить в памяти, то в нём напрашивается хранить набор пар (строка, строка), представляющих собой атрибуты и их значения, а это может нечаянно вылиться в то, что на каждый атрибут придётся хранить три указателя: указатель на пару значений в массиве, а эта пара значений -- это пара указателей на значения. Список дочерних нодов -- это тоже список указателей. CSS -- это тоже "каскад" указателей. Сами структуры вида "шёл указатель по указателю, взял указатель за указатель, и указатель указатель указатель указатель".
Вот навскидку три возможные причины. Я полагаю, что гугл в v8 так или иначе пытается бороться с каждой (и с десятком других, которые мне не пришли в голову), но тут я не копенгаген, никогда не интересовался внутренностями v8. Можно (1) притянуть за уши к твоим многомерным массивам, и сказать, что (1) -- это лишь обобщение того, о чём ты говоришь. Но можно и не притягивать, а просто смотреть правде в глаза: многомерные массивы -- наименьшая из причин порождающая проблемы с памятью в js.
