If we don't do this, and there a class in a namespace with the same
name, type resolution gets confused between `<namespace>::<class>` and
`<class>::<constructor>`.
Instead of going through the steps of creating an empty new object,
and adding two properties ("value" and "done") to it, we can pre-bake
a shape object and cache the property offsets.
This makes creating iterator result objects in the runtime much faster.
47% speedup on this microbenchmark:
function go(a) {
for (const p of a) {
}
}
const a = [];
a.length = 1_000_000;
go(a);
Using the code that it has just produced, the JIT::Compiler can build an
ELF image so that we can attach meaningful symbols to JITted code, and
thus enable GDB to display more information about the code that we're
running.
Provide a function to create an ELF image in a format GDB expects.
Outside of ELF platforms this image doesn't make much sense, and in
MacOS a Mach-O memory image is required: see
https://chromium.googlesource.com/v8/v8.git/+/refs/heads/main/src/diagnostics/gdb-jit.cc#1802
Since GDB requires active runtime addresses for the code, copying the
generated code into the image will not help. Instead, `build_gdb_image`
writes the runtime addresses of the code into a NOBITS `.text` section.
Introduces new builders, mainly `SectionTable` and `StringTable`, and a
final `build_elf_image` to merge everything into a single memory image.
Each of the builders are fully detached from one another, although
StringTable provides an extra API to remove steps when using it with a
SectionTable.
This automates the part of figuring out and properly writing offsets to
headers, and making sure all required data is properly copied and
referenced in the final image.
The new JIT::GDB namespace enables registering JITted objects into GDB
dynamically.
Its clients just have to ensure the memory they give to
`register_into_gdb` is in a format that GDB can understand, either by
generating an object file in memory with debug info + symbols or by
registering a custom debug info parser.
None of these are implemented by this API; it only implements the
registering part and lets the client to choose the data format.
GDB JIT Interface:
https://sourceware.org/gdb/current/onlinedocs/gdb.html/JIT-Interface.html#JIT-Interface
Things to take into account from v8's docs, some of which we may
improve: https://v8.dev/docs/gdb-jit#known-limitations
When iterating over an iterable, we get back a JS object with the fields
"value" and "done".
Before this change, we've had two dedicated instructions for retrieving
the two fields: IteratorResultValue and IteratorResultDone. These had no
fast path whatsoever and just did a generic [[Get]] access to fetch the
corresponding property values.
By replacing the instructions with GetById("value") and GetById("done"),
they instantly get caching and JIT fast paths for free, making iterating
over iterables much faster. :^)
26% speed-up on this microbenchmark:
function go(a) {
for (const p of a) {
}
}
const a = [];
a.length = 1_000_000;
go(a);
This patch makes IteratorRecord an Object. Although it's not exposed to
author code, this does allow us to store it in a VM register.
Now that we can store it in a VM register, we don't need to convert it
back and forth between IteratorRecord and Object when accessing it from
bytecode.
The big win here is avoiding 3 [[Get]] accesses on every iteration step
of for..of loops. There are also a bunch of smaller efficiencies gained.
20% speed-up on this microbenchmark:
function go(a) {
for (const p of a) {
}
}
const a = [];
a.length = 1_000_000;
go(a);
