In Chrome, why are TypedArrays not on JS Heap?

If I intentionally delete memory using JS arrays in Chrome (v48), calling this again:

var rootReference; function wasteBunchOfMemoryWithJsArrays() { rootReference = rootReference || []; for (var i = 0; i < 1000; i++) { var blah = []; for (var j = 0; j < 10000; j++) { blah.push(j); } rootReference.push(blah); } } 

Then the browser tab is disabled using approximately 700 MB (according to the task manager), which roughly corresponds to the limit specified in performance.memory.jsHeapSizeLimit .

However, if I lose memory using a TypedArray such as Int32Array, calling this repeatedly:

 var typedRootReference; function wasteBunchOfMemoryWithInt32Arrays() { typedRootReference = typedRootReference || []; for (var i = 0; i < 100; i++) { var blah = new Int32Array(100000); for (var j = 0; j < 100000; j++) { blah[j] = j; } typedRootReference.push(blah); } } 

Then I can continue to go up and up until I get to what I think will be 32-bit process memory at a speed of about 2.9 GB!

Is this just a case where TypedArrays get around JS heap restrictions? What for? Is there anything else that should bother me with TypedArrays?

+5
source share
1 answer

The data stored in typed arrays, because these are all numbers, are guaranteed not to contain references to other objects, so it does not affect whether any other object is garbage. Therefore, data does not require scanning, copying or manipulation using the garbage collector.

Given this, a very common implementation strategy is to place such "clean" "bulk" data outside the garbage collector heap in order to reduce the amount of data that the garbage collector needs to manage.

There is no fundamental reason for this to mean that, as you have noticed, there must be two separate memory limits (or lack of restrictions), but if no effort is made to impose a combined memory limit, then what happens.

+4
source

Source: https://habr.com/ru/post/1243703/


All Articles