whoami
Fedor Indutny
Software Engineer @ PayPal
Node.js TSC/CTC member
Memory Layout of V8's Heap
High-level data types
options = { key: ..., cert: ... };
list = [ ... ];
instance = new Class();
function cb() {}
Readable and straightforward
sometimes...
CPU
sees data as a
Uint8Array
or Uint64Array
(no such thing) reads/writes machine words
HOW TO FIT
HIGH-LEVEL DATA
INTO
LOW-LEVEL MEDIUM?
Illustration: palerlotus
The most important
SMall
Integer
Object is represented by
Uint64Array
(non-existent)
Read value:
@read(obj, 0)
Get machine word!
What this machine word means?
Make integers great again
One bit to rule them all
Could be 1 for SMIs
Meh... too slow!
`1 + 1` in JS
will turn into
(((3 >> 1) + (3 >> 1)) << 1) | 1
0 for SMIs
2 + 2
Automatically tagged!
This tagging scheme
doesn't work for
floating point numbers
Given a pointer
what question can we ask?
Map
for each type
(pointer in first machine word,
`@read(obj, 0)`)
Maps for:
- Boolean
- String
- Object
- ...Map
Each added/removed property
Creates a child Map
Slow way
obj[@properties].forEach((p) => {
if (p.name === 'prop')
@load(obj, p.offset);
});
Stable maps → fast way
if (obj[@map] === @known-map)
@load(obj, 42);
else if (obj[@map] === @other-map)
@load(obj, 23);
else
doSlowLoad(obj, 'prop');
Pass same types of objects to
performance-critical functions
JSObject Layout
- String properties
- Number properties (elements)
- In-object properties (fast properties)
Maps have indices and names of in-object properties
llnode uses all of mentioned
memory layouts, and more!
lldb -- node
--abort_on_uncaught_exception
my-app.js