0
281
VisualizaçõesJavaScript: V8 question: are small integers reused?
According to this article from V8's blog and this existing question, we know that small integers are encoded into the pointers directly with pointer tagging.
The "trick" of Smis is that they're not stored as separate objects: when you have an object that refers to a Smi, such as let foo = {smi: 42}, then the value 42 can be smi-encoded and stored directly inside the "foo" object (whereas if the value was 42.5, then the object would store a pointer to a separate "HeapNumber"). But since the object is on the heap, so is the Smi.
This means that if I have two different objects with the same object values {smi: 42}. The smi 42 should be located in two different memory location on heap since the two objects are on heap and the value 42 is encoded directly into the pointer, instead of having an additional storage.
But this contradicts with the Chrome devtool's memory profiling result. Given this snippet
<body>
<button id='btn'>btn</button>
<script>
const btn = document.querySelector('#btn')
function MyObject() {
this.number = 3.14
this.smi = 123
this.undefined = undefined
this.true = true
this.false = false
this.null = null
this.string = 'foo'
}
let obj1
let obj2
btn.onclick = () => {
obj1 = new MyObject()
obj2 = new MyObject()
}
</script>
</body>
I thought smi:123 should be located in two different locations while double number = 3.14 should point to the same number object.
But this is not what happened - smi are in the same memory location and double are not.
2 Respostas
Responde à pergunta0
An additional comment to @JonasWilms' great answer:
If you actually care about what happens under the hood, I suggest you learn how to use a (native, not DevTools) debugger and inspect the actual memory. DevTools are designed to help you understand what your app is doing, and while that has a lot of overlap with surfacing what's happening under the hood, it's not exactly the same thing, and there may well be certain details (like how Smis are presented) where this difference shows. I think heap snapshots use a raw_address → object ID map, and what you see is the natural result of putting Smis into such a map.
For a simplified version of your test case (just function MyObject() { this.number = 12.5; this.smi = 23; }), this is what you'd see in memory:
(gdb) x/5xw 0x1f010810aedc
0x1f010810aedc: 0x082c7db1 // pointer to map
0x08002249 // pointer to properties (empty array)
0x08002249 // pointer to elements (empty array)
0x0810af71 // pointer to a HeapNumber
0x0000002e // Smi: 23 << 1 == 46 == 0x2e
(gdb) x/5xw 0x1f010810afa4
0x1f010810afa4: 0x082c7db1 // map (same as other object)
0x08002249 // properties
0x08002249 // elements
0x0810afd9 // pointer to a HeapNumber
0x0000002e // Smi: 23 << 1
On another note, HeapNumbers can and do get reused. We don't see that in this example because of yet another mechanism: object properties use mutable HeapNumbers. Being mutable makes them unshareable, and in this toy example the whole approach just wastes time and memory; but it turns out to be a beneficial tradeoff for typical usage patterns, because it allows updating the value (in particular, from optimized code) without allocating a new HeapNumber every time.
If you simply had a function f() { return 12.5; }, it would actually return the same reused HeapNumber every time it's called.
0
The smi 42 should be located in two different memory location on heap since the two objects are on heap and the value 42 is encoded directly into the pointer, instead of having an additional storage.
Yes. The SMI is stored twice, once inside each object values. So no, they're not reused, and actually can't be, as they're primitive values and not something referencable.
The dev tools do not show where the pointer resides in memory but rather where it points to, which in case of an SMI is a nonsense location as it actually encodes the value. Thus as both encode the same value, their "pointer to nothing" is the same.