When iterating over vanilla objects/arrays with normal property storage,
we can skip the generic Get mechanism in favor of looking directly at
property storage. This is essentially what we do in the bytecode path.
`MM.protect_kernel_image` would otherwise make the contents of these
sections read-only, as they were for some reason placed before `.data`
and after the start of `.text`.
Originally, the input was named `tokens`, and we later created a
`tokens_without_whitespace` from the filtered contents of `tokens`.
Since `tokens_without_whitespace` is what we actually want to use while
parsing, let's rename `tokens` -> `unprocessed_tokens` and use the
`tokens` name for the processed ones.
This fixes an elusive issue where changing the hovered node would cause
a JS event handler to run, changing the shape of the paint tree before
we had a chance to get the cursor.
A more robust fix here will be to let paintables own their used/computed
values (so they don't have to look into the layout tree for them) but
that's a much bigger change.
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.
