Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2026-04-18 18:00:31 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibJS/Bytecode/Interpreter.cpp

3408 lines
150 KiB
C++
Raw Normal View History

LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
/*
LibJS: Store Module::environment() as ModuleEnvironment Let's use a more specific type here to allow for devirtualization.
2025-03-16 17:41:24 -05:00
* Copyright (c) 2021-2025, Andreas Kling <andreas@ladybird.org>
LibJS: Skip iterator result object allocation in for..of and for..in Introduce special instruction for `for..of` and `for..in` loop that skips `{ value, done }` result object allocation if iterator is builtin (array, map, set, string). This reduces GC pressure significantly and avoids extracting the `value` and `done` properties. This change makes this micro benchmark 48% faster on my computer: ```js const arr = new Array(10_000_000); let counter = 0; for (let _ of arr) { counter++; } ```
2025-04-30 16:31:26 +03:00
* Copyright (c) 2025, Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
LibJS: Move bytecode debug spam behind JS_BYTECODE_DEBUG :^)
2021-06-07 15:17:37 +02:00
#include <AK/Debug.h>
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
#include <AK/HashTable.h>
LibJS: Store strings in a string table Instead of using Strings in the bytecode ops this adds a global string table to the Executable struct which individual operations can refer to using indices. This brings bytecode ops one step closer to being pointer free.
2021-06-09 10:02:01 +02:00
#include <AK/TemporaryChange.h>
LibJS: Avoid Value->PropertyKey->Value roundtrip in for..in iteration Before this change, we would call [[OwnPropertyKeys]] on the target objects, then convert the returned keys from Value into PropertyKey. Then, when actually iterating, we'd convert them back into Value again. This was particularly costly for numeric property keys, since we had to go through string-from-number construction. Now, we simply keep the original values returned by [[OwnPropertyKeys]] around and use them for the enumeration. 1.09x speedup on MicroBench/for-in-indexed-properties.js 1.01x speedup on MicroBench/for-in-named-properties.js
2025-05-03 11:35:22 +02:00
#include <LibGC/RootHashMap.h>
LibJS/Bytecode: Leave GlobalDeclarationInstantiation in C++ Don't try to implement this AO in bytecode. Instead, the bytecode Interpreter class now has a run() API with the same inputs as the AST interpreter. It sets up the necessary environments etc, including invoking the GlobalDeclarationInstantiation AO.
2023-06-15 12:36:57 +02:00
#include <LibJS/AST.h>
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
#include <LibJS/Bytecode/AsmInterpreter/AsmInterpreter.h>
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
#include <LibJS/Bytecode/BasicBlock.h>
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
#include <LibJS/Bytecode/FormatOperand.h>
Ladybird+LibJS: Add CLI option to run browser with LibJS bytecode VM This required quite a bit of plumbing, but now you can run ladybird --use-bytecode
2023-06-17 13:16:35 +02:00
#include <LibJS/Bytecode/Generator.h>
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
#include <LibJS/Bytecode/Instruction.h>
#include <LibJS/Bytecode/Interpreter.h>
LibJS: Use static unwind mappings for unwind related functions
2023-10-20 00:33:51 +02:00
#include <LibJS/Bytecode/Label.h>
LibJS: Move Bytecode::Instruction::execute() to the Op.h header ..and make sure it always gets inlined in the interpreter loop.
2021-06-09 09:19:34 +02:00
#include <LibJS/Bytecode/Op.h>
LibJS: Move GetById logic to a separate header to prepare for reuse We also make the code a bit more generic by making callers provide (templated) callbacks that produce the property name and base expression string if any.
2025-10-14 13:23:55 +02:00
#include <LibJS/Bytecode/PropertyAccess.h>
LibJS: Add minimum changes to build on Windows and run js.exe This commit adds the minimal export macros needed to run js.exe on windows. A followup commit is planned to move to explicit export entirely. A static_assert for the size of a struct is also ifdef'ed out as the semantics around object layout and inheritance are different on MSVC abi and the struct IteratorRecord ends up being 40 bytes not 32.
2025-05-24 23:46:13 +02:00
#include <LibJS/Export.h>
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
#include <LibJS/Runtime/AbstractOperations.h>
LibJS: Allow GetById to cache getters 1.25x speed-up on this microbenchmark: let o = { get x() { return 1; } }; for (let i = 0; i < 10_000_000; ++i) o.x; I looked into this because I noticed getter invocation when profiling long-running WPT tests. We already had the mechanism for non-getter properties, and the change to support getters turned out to be trivial.
2024-10-17 20:29:07 +02:00
#include <LibJS/Runtime/Accessor.h>
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
#include <LibJS/Runtime/Array.h>
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
#include <LibJS/Runtime/AsyncFromSyncIterator.h>
#include <LibJS/Runtime/AsyncFromSyncIteratorPrototype.h>
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
#include <LibJS/Runtime/BigInt.h>
LibJS: Wire NewClass to ClassBlueprint Replace the ClassExpression const& reference in the NewClass instruction with a u32 class_blueprint_index. The interpreter now reads from the ClassBlueprint stored on the Executable and calls construct_class() instead of the AST-based create_class_constructor(). Literal field initializers (numbers, booleans, null, strings, negated numbers) are used directly in construct_class() without creating an ECMAScriptFunctionObject, avoiding function creation overhead for common field patterns like `x = 0` or `name = "hello"`. Set class_field_initializer_name on SharedFunctionInstanceData at codegen time for statically-known field keys (identifiers, private identifiers, string literals, and numeric literals). For computed keys, the name is set at runtime in construct_class(). ClassExpression AST nodes are no longer referenced from bytecode.
2026-02-11 00:28:10 +01:00
#include <LibJS/Runtime/ClassConstruction.h>
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
#include <LibJS/Runtime/CompletionCell.h>
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
#include <LibJS/Runtime/DeclarativeEnvironment.h>
#include <LibJS/Runtime/ECMAScriptFunctionObject.h>
#include <LibJS/Runtime/Environment.h>
#include <LibJS/Runtime/FunctionEnvironment.h>
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
#include <LibJS/Runtime/GeneratorResult.h>
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
#include <LibJS/Runtime/GlobalEnvironment.h>
LibJS: Add a VM accessor to Bytecode::Interpreter :^)
2021-06-03 18:26:13 +02:00
#include <LibJS/Runtime/GlobalObject.h>
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
#include <LibJS/Runtime/Iterator.h>
LibJS: Call builtins directly in the bytecode interpreter Allows the bytecode interpreter to call the builtins c++ implementation directly without making a javascript call just as the JIT. Kraken test speedups: imaging-gaussian-blur.js (1.5x) and audio-oscillator.js (1.2x)
2023-11-30 19:49:29 +01:00
#include <LibJS/Runtime/MathObject.h>
LibJS: Store Module::environment() as ModuleEnvironment Let's use a more specific type here to allow for devirtualization.
2025-03-16 17:41:24 -05:00
#include <LibJS/Runtime/ModuleEnvironment.h>
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
#include <LibJS/Runtime/NativeFunction.h>
#include <LibJS/Runtime/ObjectEnvironment.h>
LibJS: Move the GlobalEnvironment from GlobalObject to Realm This is where the spec wants to have it. Requires a couple of hacks as currently everything that needs a Realm actually has a GlobalObject, so we need to go via the Interpreter.
2021-09-11 20:27:36 +01:00
#include <LibJS/Runtime/Realm.h>
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
#include <LibJS/Runtime/Reference.h>
#include <LibJS/Runtime/RegExpObject.h>
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
#include <LibJS/Runtime/TypedArray.h>
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
#include <LibJS/Runtime/Value.h>
LibJS: Inline fast case for Value::to_{boolean,number,numeric,primitive} These functions all have a very common case that can be dealt with a very simple inline check, often avoiding the need to call an out-of-line function. This patch moves the common case to inline functions in a new ValueInlines.h header (necessary due to header dependency issues..) 8% speed-up on the entire Kraken benchmark :^)
2023-10-06 17:54:21 +02:00
#include <LibJS/Runtime/ValueInlines.h>
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
#include <LibJS/SourceTextModule.h>
LibJS: Add % (modulo) fast path in bytecode interpreter We can avoid the expensive call to fmod() in various cases when we have Int32 values on both sides of the operator.
2026-01-08 23:46:59 +01:00
#include <math.h>
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
namespace JS::Bytecode {
LibJS: Move global "should dump bytecode" flag into LibJS This will allow us to trigger bytecode executable dumps when generating bytecode inside LibJS as well, not just in clients like js and test-js.
2021-10-24 13:34:46 +02:00
bool g_dump_bytecode = false;
LibJS: Compile ScriptFunctions into bytecode and run them that way :^) If there's a current Bytecode::Interpreter in action, ScriptFunction will now compile itself into bytecode and execute in that context. This patch also adds the Return bytecode instruction so that we can actually return values from called functions. :^) Return values are propagated from callee to caller via the caller's $0 register. Bytecode::Interpreter now keeps a stack of register "windows". These are not very efficient, but it should be pretty straightforward to convert them to e.g a sliding register window architecture later on. This is pretty dang cool! :^)
2021-06-05 15:53:36 +02:00
LibJS: Avoid roundtrip through Value for comparison bytecode evaluation 1.1x speedup on strictly-equals-object.js
2025-05-08 15:19:35 +12:00
ALWAYS_INLINE static ThrowCompletionOr<bool> loosely_inequals(VM& vm, Value src1, Value src2)
LibJS/Bytecode: Add peephole optimization pass and fuse compare+jump This patch adds a new "Peephole" pass for performing small, local optimizations to bytecode. We also introduce the first such optimization, fusing a sequence of some comparison instruction FooCompare followed by a JumpIf into a new set of JumpFooCompare instructions. This gives a ~50% speed-up on the following microbenchmark: for (let i = 0; i < 10_000_000; ++i) { } But more traditional benchmarks see a pretty sizable speed-up as well, for example 15% on Kraken/ai-astar.js and 16% on Kraken/audio-dft.js :^)
2024-03-03 14:56:33 +01:00
{
LibJS/Bytecode: Add fast paths for equality checks with same-tag values
2024-03-04 09:34:30 +01:00
if (src1.tag() == src2.tag()) {
if (src1.is_int32() || src1.is_object() || src1.is_boolean() || src1.is_nullish())
LibJS: Avoid roundtrip through Value for comparison bytecode evaluation 1.1x speedup on strictly-equals-object.js
2025-05-08 15:19:35 +12:00
return src1.encoded() != src2.encoded();
LibJS/Bytecode: Add fast paths for equality checks with same-tag values
2024-03-04 09:34:30 +01:00
}
LibJS: Avoid roundtrip through Value for comparison bytecode evaluation 1.1x speedup on strictly-equals-object.js
2025-05-08 15:19:35 +12:00
return !TRY(is_loosely_equal(vm, src1, src2));
LibJS/Bytecode: Add peephole optimization pass and fuse compare+jump This patch adds a new "Peephole" pass for performing small, local optimizations to bytecode. We also introduce the first such optimization, fusing a sequence of some comparison instruction FooCompare followed by a JumpIf into a new set of JumpFooCompare instructions. This gives a ~50% speed-up on the following microbenchmark: for (let i = 0; i < 10_000_000; ++i) { } But more traditional benchmarks see a pretty sizable speed-up as well, for example 15% on Kraken/ai-astar.js and 16% on Kraken/audio-dft.js :^)
2024-03-03 14:56:33 +01:00
}
LibJS: Avoid roundtrip through Value for comparison bytecode evaluation 1.1x speedup on strictly-equals-object.js
2025-05-08 15:19:35 +12:00
ALWAYS_INLINE static ThrowCompletionOr<bool> loosely_equals(VM& vm, Value src1, Value src2)
LibJS/Bytecode: Add peephole optimization pass and fuse compare+jump This patch adds a new "Peephole" pass for performing small, local optimizations to bytecode. We also introduce the first such optimization, fusing a sequence of some comparison instruction FooCompare followed by a JumpIf into a new set of JumpFooCompare instructions. This gives a ~50% speed-up on the following microbenchmark: for (let i = 0; i < 10_000_000; ++i) { } But more traditional benchmarks see a pretty sizable speed-up as well, for example 15% on Kraken/ai-astar.js and 16% on Kraken/audio-dft.js :^)
2024-03-03 14:56:33 +01:00
{
LibJS/Bytecode: Add fast paths for equality checks with same-tag values
2024-03-04 09:34:30 +01:00
if (src1.tag() == src2.tag()) {
if (src1.is_int32() || src1.is_object() || src1.is_boolean() || src1.is_nullish())
LibJS: Avoid roundtrip through Value for comparison bytecode evaluation 1.1x speedup on strictly-equals-object.js
2025-05-08 15:19:35 +12:00
return src1.encoded() == src2.encoded();
LibJS/Bytecode: Add fast paths for equality checks with same-tag values
2024-03-04 09:34:30 +01:00
}
LibJS: Avoid roundtrip through Value for comparison bytecode evaluation 1.1x speedup on strictly-equals-object.js
2025-05-08 15:19:35 +12:00
return TRY(is_loosely_equal(vm, src1, src2));
LibJS/Bytecode: Add peephole optimization pass and fuse compare+jump This patch adds a new "Peephole" pass for performing small, local optimizations to bytecode. We also introduce the first such optimization, fusing a sequence of some comparison instruction FooCompare followed by a JumpIf into a new set of JumpFooCompare instructions. This gives a ~50% speed-up on the following microbenchmark: for (let i = 0; i < 10_000_000; ++i) { } But more traditional benchmarks see a pretty sizable speed-up as well, for example 15% on Kraken/ai-astar.js and 16% on Kraken/audio-dft.js :^)
2024-03-03 14:56:33 +01:00
}
LibJS: Avoid roundtrip through Value for comparison bytecode evaluation 1.1x speedup on strictly-equals-object.js
2025-05-08 15:19:35 +12:00
ALWAYS_INLINE static ThrowCompletionOr<bool> strict_inequals(VM&, Value src1, Value src2)
LibJS/Bytecode: Add peephole optimization pass and fuse compare+jump This patch adds a new "Peephole" pass for performing small, local optimizations to bytecode. We also introduce the first such optimization, fusing a sequence of some comparison instruction FooCompare followed by a JumpIf into a new set of JumpFooCompare instructions. This gives a ~50% speed-up on the following microbenchmark: for (let i = 0; i < 10_000_000; ++i) { } But more traditional benchmarks see a pretty sizable speed-up as well, for example 15% on Kraken/ai-astar.js and 16% on Kraken/audio-dft.js :^)
2024-03-03 14:56:33 +01:00
{
LibJS/Bytecode: Add fast paths for equality checks with same-tag values
2024-03-04 09:34:30 +01:00
if (src1.tag() == src2.tag()) {
if (src1.is_int32() || src1.is_object() || src1.is_boolean() || src1.is_nullish())
LibJS: Avoid roundtrip through Value for comparison bytecode evaluation 1.1x speedup on strictly-equals-object.js
2025-05-08 15:19:35 +12:00
return src1.encoded() != src2.encoded();
LibJS/Bytecode: Add fast paths for equality checks with same-tag values
2024-03-04 09:34:30 +01:00
}
LibJS: Avoid roundtrip through Value for comparison bytecode evaluation 1.1x speedup on strictly-equals-object.js
2025-05-08 15:19:35 +12:00
return !is_strictly_equal(src1, src2);
LibJS/Bytecode: Add peephole optimization pass and fuse compare+jump This patch adds a new "Peephole" pass for performing small, local optimizations to bytecode. We also introduce the first such optimization, fusing a sequence of some comparison instruction FooCompare followed by a JumpIf into a new set of JumpFooCompare instructions. This gives a ~50% speed-up on the following microbenchmark: for (let i = 0; i < 10_000_000; ++i) { } But more traditional benchmarks see a pretty sizable speed-up as well, for example 15% on Kraken/ai-astar.js and 16% on Kraken/audio-dft.js :^)
2024-03-03 14:56:33 +01:00
}
LibJS: Avoid roundtrip through Value for comparison bytecode evaluation 1.1x speedup on strictly-equals-object.js
2025-05-08 15:19:35 +12:00
ALWAYS_INLINE static ThrowCompletionOr<bool> strict_equals(VM&, Value src1, Value src2)
LibJS/Bytecode: Add peephole optimization pass and fuse compare+jump This patch adds a new "Peephole" pass for performing small, local optimizations to bytecode. We also introduce the first such optimization, fusing a sequence of some comparison instruction FooCompare followed by a JumpIf into a new set of JumpFooCompare instructions. This gives a ~50% speed-up on the following microbenchmark: for (let i = 0; i < 10_000_000; ++i) { } But more traditional benchmarks see a pretty sizable speed-up as well, for example 15% on Kraken/ai-astar.js and 16% on Kraken/audio-dft.js :^)
2024-03-03 14:56:33 +01:00
{
LibJS/Bytecode: Add fast paths for equality checks with same-tag values
2024-03-04 09:34:30 +01:00
if (src1.tag() == src2.tag()) {
if (src1.is_int32() || src1.is_object() || src1.is_boolean() || src1.is_nullish())
LibJS: Avoid roundtrip through Value for comparison bytecode evaluation 1.1x speedup on strictly-equals-object.js
2025-05-08 15:19:35 +12:00
return src1.encoded() == src2.encoded();
LibJS/Bytecode: Add fast paths for equality checks with same-tag values
2024-03-04 09:34:30 +01:00
}
LibJS: Avoid roundtrip through Value for comparison bytecode evaluation 1.1x speedup on strictly-equals-object.js
2025-05-08 15:19:35 +12:00
return is_strictly_equal(src1, src2);
LibJS/Bytecode: Add peephole optimization pass and fuse compare+jump This patch adds a new "Peephole" pass for performing small, local optimizations to bytecode. We also introduce the first such optimization, fusing a sequence of some comparison instruction FooCompare followed by a JumpIf into a new set of JumpFooCompare instructions. This gives a ~50% speed-up on the following microbenchmark: for (let i = 0; i < 10_000_000; ++i) { } But more traditional benchmarks see a pretty sizable speed-up as well, for example 15% on Kraken/ai-astar.js and 16% on Kraken/audio-dft.js :^)
2024-03-03 14:56:33 +01:00
}
LibJS: Introduce VM::the() and use it instead of caching VM pointer In our process architecture, there's only ever one JS::VM per process. This allows us to have a VM::the() singleton getter that optimizes down to a single global access everywhere. Seeing 1-2% speed-up on all JS benchmarks from this.
2025-12-09 10:35:41 -06:00
Interpreter::Interpreter() = default;
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
LibJS: Introduce VM::the() and use it instead of caching VM pointer In our process architecture, there's only ever one JS::VM per process. This allows us to have a VM::the() singleton getter that optimizes down to a single global access everywhere. Seeing 1-2% speed-up on all JS benchmarks from this.
2025-12-09 10:35:41 -06:00
Interpreter::~Interpreter() = default;
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
LibJS: Prepare yield object before re-routing it through finally
2024-05-18 17:25:43 +02:00
ALWAYS_INLINE Value Interpreter::do_yield(Value value, Optional<Label> continuation)
{
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
// FIXME: If we get a pointer, which is not accurately representable as a double
// will cause this to explode
auto continuation_value = continuation.has_value() ? Value(continuation->address()) : js_null();
return vm().heap().allocate<GeneratorResult>(value, continuation_value, false).ptr();
LibJS: Prepare yield object before re-routing it through finally
2024-05-18 17:25:43 +02:00
}
LibJS/Bytecode: Leave GlobalDeclarationInstantiation in C++ Don't try to implement this AO in bytecode. Instead, the bytecode Interpreter class now has a run() API with the same inputs as the AST interpreter. It sets up the necessary environments etc, including invoking the GlobalDeclarationInstantiation AO.
2023-06-15 12:36:57 +02:00
// 16.1.6 ScriptEvaluation ( scriptRecord ), https://tc39.es/ecma262/#sec-runtime-semantics-scriptevaluation
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
ThrowCompletionOr<Value> Interpreter::run(Script& script_record, GC::Ptr<Environment> lexical_environment_override)
LibJS/Bytecode: Leave GlobalDeclarationInstantiation in C++ Don't try to implement this AO in bytecode. Instead, the bytecode Interpreter class now has a run() API with the same inputs as the AST interpreter. It sets up the necessary environments etc, including invoking the GlobalDeclarationInstantiation AO.
2023-06-15 12:36:57 +02:00
{
auto& vm = this->vm();
// 1. Let globalEnv be scriptRecord.[[Realm]].[[GlobalEnv]].
auto& global_environment = script_record.realm().global_environment();
LibJS+LibWeb: Calculate count of regs+consts+locals before EC allocation This is a preparation step before joining arguments vector into vector of registers+constants+locals.
2025-04-22 21:49:41 +02:00
// NOTE: Spec steps are rearranged in order to compute number of registers+constants+locals before construction of the execution context.
// 12. Let result be Completion(GlobalDeclarationInstantiation(script, globalEnv)).
LibJS: Rewrite global declaration instantiation using metadata Add Script::global_declaration_instantiation() that performs the GDI algorithm using pre-computed name lists and shared function data instead of walking the AST. Runtime checks (has_lexical_declaration, can_declare_global_function, etc.) remain since they depend on global environment state. AnnexB iterates pre-collected candidates and calls set_should_do_additional_annexB_steps() on stored refs. The Interpreter::run(Script&) now calls the Script method instead of the Program method.
2026-02-11 01:48:19 +01:00
auto instantiation_result = script_record.global_declaration_instantiation(vm, global_environment);
LibJS+LibWeb: Calculate count of regs+consts+locals before EC allocation This is a preparation step before joining arguments vector into vector of registers+constants+locals.
2025-04-22 21:49:41 +02:00
Completion result = instantiation_result.is_throw_completion() ? instantiation_result.throw_completion() : normal_completion(js_undefined());
LibJS: Rewrite global declaration instantiation using metadata Add Script::global_declaration_instantiation() that performs the GDI algorithm using pre-computed name lists and shared function data instead of walking the AST. Runtime checks (has_lexical_declaration, can_declare_global_function, etc.) remain since they depend on global environment state. AnnexB iterates pre-collected candidates and calls set_should_do_additional_annexB_steps() on stored refs. The Interpreter::run(Script&) now calls the Script method instead of the Program method.
2026-02-11 01:48:19 +01:00
// 11. Let script be scriptRecord.[[ECMAScriptCode]].
LibJS: Cache compiled executable on Script Instead of recompiling from AST on every run, cache the compiled bytecode executable after first compilation and reuse it on subsequent runs.
2026-02-11 01:42:41 +01:00
GC::Ptr<Executable> executable = script_record.cached_executable();
if (!executable && result.type() == Completion::Type::Normal) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
executable = JS::Bytecode::Generator::generate_from_ast_node(vm, *script_record.parse_node(), {});
LibJS: Add alternative source-to-bytecode pipeline in Rust Implement a complete Rust reimplementation of the LibJS frontend: lexer, parser, AST, scope collector, and bytecode code generator. The Rust pipeline is built via Corrosion (CMake-Cargo bridge) and linked into LibJS as a static library. It is gated behind a build flag (ENABLE_RUST, on by default except on Windows) and two runtime environment variables: - LIBJS_CPP: Use the C++ pipeline instead of Rust - LIBJS_COMPARE_PIPELINES=1: Run both pipelines in lockstep, aborting on any difference in AST or bytecode generated. The C++ side communicates with Rust through a C FFI layer (RustIntegration.cpp/h) that passes source text to Rust and receives a populated Executable back via a BytecodeFactory interface.
2026-02-23 11:50:46 +01:00
if (executable) {
script_record.cache_executable(*executable);
script_record.drop_ast();
}
LibJS+LibWeb: Calculate count of regs+consts+locals before EC allocation This is a preparation step before joining arguments vector into vector of registers+constants+locals.
2025-04-22 21:49:41 +02:00
}
LibJS: Add alternative source-to-bytecode pipeline in Rust Implement a complete Rust reimplementation of the LibJS frontend: lexer, parser, AST, scope collector, and bytecode code generator. The Rust pipeline is built via Corrosion (CMake-Cargo bridge) and linked into LibJS as a static library. It is gated behind a build flag (ENABLE_RUST, on by default except on Windows) and two runtime environment variables: - LIBJS_CPP: Use the C++ pipeline instead of Rust - LIBJS_COMPARE_PIPELINES=1: Run both pipelines in lockstep, aborting on any difference in AST or bytecode generated. The C++ side communicates with Rust through a C FFI layer (RustIntegration.cpp/h) that passes source text to Rust and receives a populated Executable back via a BytecodeFactory interface.
2026-02-23 11:50:46 +01:00
if (executable && g_dump_bytecode)
executable->dump();
LibJS+LibWeb: Calculate count of regs+consts+locals before EC allocation This is a preparation step before joining arguments vector into vector of registers+constants+locals.
2025-04-22 21:49:41 +02:00
LibJS: Skip initializing constant slots in ExecutionContext Every function call allocates an ExecutionContext with a trailing array of Values for registers, locals, constants, and arguments. Previously, the constructor would initialize all slots to js_special_empty_value(), but constant slots were then immediately overwritten by the interpreter copying in values from the Executable before execution began. To eliminate this redundant initialization, we rearrange the layout from [registers | constants | locals] to [registers | locals | constants]. This groups registers and locals together at the front, allowing us to initialize only those slots while leaving constant slots uninitialized until they're populated with their actual values. This reduces the per-call initialization cost from O(registers + locals + constants) to O(registers + locals). Also tightens up the types involved (size_t -> u32) and adds VERIFYs to guard against overflow when computing the combined slot counts, and to ensure the total fits within the 29-bit operand index field.
2026-01-18 23:17:10 +01:00
u32 registers_and_locals_count = 0;
u32 constants_count = 0;
LibJS+LibWeb: Calculate count of regs+consts+locals before EC allocation This is a preparation step before joining arguments vector into vector of registers+constants+locals.
2025-04-22 21:49:41 +02:00
if (executable) {
LibJS: Skip initializing constant slots in ExecutionContext Every function call allocates an ExecutionContext with a trailing array of Values for registers, locals, constants, and arguments. Previously, the constructor would initialize all slots to js_special_empty_value(), but constant slots were then immediately overwritten by the interpreter copying in values from the Executable before execution began. To eliminate this redundant initialization, we rearrange the layout from [registers | constants | locals] to [registers | locals | constants]. This groups registers and locals together at the front, allowing us to initialize only those slots while leaving constant slots uninitialized until they're populated with their actual values. This reduces the per-call initialization cost from O(registers + locals + constants) to O(registers + locals). Also tightens up the types involved (size_t -> u32) and adds VERIFYs to guard against overflow when computing the combined slot counts, and to ensure the total fits within the 29-bit operand index field.
2026-01-18 23:17:10 +01:00
registers_and_locals_count = executable->registers_and_locals_count;
constants_count = executable->constants.size();
LibJS+LibWeb: Calculate count of regs+consts+locals before EC allocation This is a preparation step before joining arguments vector into vector of registers+constants+locals.
2025-04-22 21:49:41 +02:00
}
LibJS/Bytecode: Leave GlobalDeclarationInstantiation in C++ Don't try to implement this AO in bytecode. Instead, the bytecode Interpreter class now has a run() API with the same inputs as the AST interpreter. It sets up the necessary environments etc, including invoking the GlobalDeclarationInstantiation AO.
2023-06-15 12:36:57 +02:00
// 2. Let scriptContext be a new ECMAScript code execution context.
LibJS+LibWeb: Use InterpreterStack for all execution context allocation Replace alloca-based execution context allocation with InterpreterStack bump allocation across all call sites: bytecode call instructions, AbstractOperations call/construct, script evaluation, module evaluation, and LibWeb module script evaluation. Also replace the native stack space check with an InterpreterStack exhaustion check, and remove the now-unused alloca macros from ExecutionContext.h.
2026-03-04 10:32:01 +01:00
auto& stack = vm.interpreter_stack();
auto* stack_mark = stack.top();
auto* script_context = stack.allocate(registers_and_locals_count, constants_count, 0);
if (!script_context) [[unlikely]]
return vm.throw_completion<InternalError>(ErrorType::CallStackSizeExceeded);
ScopeGuard deallocate_guard = [&stack, stack_mark] { stack.deallocate(stack_mark); };
LibJS/Bytecode: Leave GlobalDeclarationInstantiation in C++ Don't try to implement this AO in bytecode. Instead, the bytecode Interpreter class now has a run() API with the same inputs as the AST interpreter. It sets up the necessary environments etc, including invoking the GlobalDeclarationInstantiation AO.
2023-06-15 12:36:57 +02:00
// 3. Set the Function of scriptContext to null.
// NOTE: This was done during execution context construction.
// 4. Set the Realm of scriptContext to scriptRecord.[[Realm]].
LibJS: Always allocate ExecutionContext objects on the malloc heap Instead of allocating these in a mixture of ways, we now always put them on the malloc heap, and keep an intrusive linked list of them that we can iterate for GC marking purposes.
2023-11-27 16:45:45 +01:00
script_context->realm = &script_record.realm();
LibJS/Bytecode: Leave GlobalDeclarationInstantiation in C++ Don't try to implement this AO in bytecode. Instead, the bytecode Interpreter class now has a run() API with the same inputs as the AST interpreter. It sets up the necessary environments etc, including invoking the GlobalDeclarationInstantiation AO.
2023-06-15 12:36:57 +02:00
// 5. Set the ScriptOrModule of scriptContext to scriptRecord.
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
script_context->script_or_module = GC::Ref<Script>(script_record);
LibJS/Bytecode: Leave GlobalDeclarationInstantiation in C++ Don't try to implement this AO in bytecode. Instead, the bytecode Interpreter class now has a run() API with the same inputs as the AST interpreter. It sets up the necessary environments etc, including invoking the GlobalDeclarationInstantiation AO.
2023-06-15 12:36:57 +02:00
// 6. Set the VariableEnvironment of scriptContext to globalEnv.
LibJS: Always allocate ExecutionContext objects on the malloc heap Instead of allocating these in a mixture of ways, we now always put them on the malloc heap, and keep an intrusive linked list of them that we can iterate for GC marking purposes.
2023-11-27 16:45:45 +01:00
script_context->variable_environment = &global_environment;
LibJS/Bytecode: Leave GlobalDeclarationInstantiation in C++ Don't try to implement this AO in bytecode. Instead, the bytecode Interpreter class now has a run() API with the same inputs as the AST interpreter. It sets up the necessary environments etc, including invoking the GlobalDeclarationInstantiation AO.
2023-06-15 12:36:57 +02:00
// 7. Set the LexicalEnvironment of scriptContext to globalEnv.
LibJS: Always allocate ExecutionContext objects on the malloc heap Instead of allocating these in a mixture of ways, we now always put them on the malloc heap, and keep an intrusive linked list of them that we can iterate for GC marking purposes.
2023-11-27 16:45:45 +01:00
script_context->lexical_environment = &global_environment;
LibJS/Bytecode: Leave GlobalDeclarationInstantiation in C++ Don't try to implement this AO in bytecode. Instead, the bytecode Interpreter class now has a run() API with the same inputs as the AST interpreter. It sets up the necessary environments etc, including invoking the GlobalDeclarationInstantiation AO.
2023-06-15 12:36:57 +02:00
Revert "LibJS+LibWeb: Remove now-unused lexical environment override" This reverts commit d39f6975f9c8209d422734b830ad22196a54b79d.
2024-10-31 08:03:09 -04:00
// Non-standard: Override the lexical environment if requested.
if (lexical_environment_override)
script_context->lexical_environment = lexical_environment_override;
LibJS/Bytecode: Leave GlobalDeclarationInstantiation in C++ Don't try to implement this AO in bytecode. Instead, the bytecode Interpreter class now has a run() API with the same inputs as the AST interpreter. It sets up the necessary environments etc, including invoking the GlobalDeclarationInstantiation AO.
2023-06-15 12:36:57 +02:00
// 8. Set the PrivateEnvironment of scriptContext to null.
LibJS: Remove unneeded FIXMEs for suspending an execution context From what I understand, the suspension steps are not required now, or in the future for our implementation, or any other. The intent is already implemented in the spec pushing on another execution context to the stack and leaving the running execution context as-is. The resume steps are a slightly different story as there is some subtle behavior which the spec is trying to convey where some custom logic may need to be done when one execution context changes from one to another. It may be worth implementing those steps at a later point in time so that this behavior is a bit easier to follow in those cases. To make the situation more confusing - from what I can gather from the spec, not all cases that the spec mentions resume actually means anything normative. Resume is only _actually_ needed in a limited set of locations. For now, let's just remove the unneeded FIXMEs that indicate that there is something to be done for the suspension steps, as there is not, and leave the resume steps as is.
2025-01-01 22:51:52 +13:00
// 9. Suspend the currently running execution context.
LibJS/Bytecode: Leave GlobalDeclarationInstantiation in C++ Don't try to implement this AO in bytecode. Instead, the bytecode Interpreter class now has a run() API with the same inputs as the AST interpreter. It sets up the necessary environments etc, including invoking the GlobalDeclarationInstantiation AO.
2023-06-15 12:36:57 +02:00
// 10. Push scriptContext onto the execution context stack; scriptContext is now the running execution context.
LibJS: Always allocate ExecutionContext objects on the malloc heap Instead of allocating these in a mixture of ways, we now always put them on the malloc heap, and keep an intrusive linked list of them that we can iterate for GC marking purposes.
2023-11-27 16:45:45 +01:00
TRY(vm.push_execution_context(*script_context, {}));
LibJS/Bytecode: Leave GlobalDeclarationInstantiation in C++ Don't try to implement this AO in bytecode. Instead, the bytecode Interpreter class now has a run() API with the same inputs as the AST interpreter. It sets up the necessary environments etc, including invoking the GlobalDeclarationInstantiation AO.
2023-06-15 12:36:57 +02:00
// 13. If result.[[Type]] is normal, then
LibJS: Check result of GlobalDeclarationInstantiation before evaluating Per step 13 of ScriptEvaluation in the ECMA-262 spec, the script body should only be evaluated if GlobalDeclarationInstantiation returned a normal completion. This can't currently be triggered since we always create fresh Script objects, but if we ever start reusing cached executables across evaluations, this would prevent a subtle bug where the script body runs despite GDI failing.
2026-02-19 11:14:26 +01:00
if (executable && result.type() == Completion::Type::Normal) {
LibJS: Remove redundant completion type check in ScriptEvaluation See editorial change to the ECMA-262 spec of: https://github.com/tc39/ecma262/commit/bc5b7fda5
2025-01-02 01:56:00 +13:00
// a. Set result to Completion(Evaluation of script).
LibJS: Make run_executable() return simple ThrowCompletionOr<Value> We don't need to return two values; running an executable only ever produces a throw completion, or a normal completion, i.e a Value. This necessitated a few minor changes, such as adding a way to check if a JS::Cell is a GeneratorResult.
2025-10-30 10:27:47 +01:00
result = run_executable(*script_context, *executable, {}, {});
LibJS/Bytecode: Leave GlobalDeclarationInstantiation in C++ Don't try to implement this AO in bytecode. Instead, the bytecode Interpreter class now has a run() API with the same inputs as the AST interpreter. It sets up the necessary environments etc, including invoking the GlobalDeclarationInstantiation AO.
2023-06-15 12:36:57 +02:00
LibJS: Remove redundant completion type check in ScriptEvaluation See editorial change to the ECMA-262 spec of: https://github.com/tc39/ecma262/commit/bc5b7fda5
2025-01-02 01:56:00 +13:00
// b. If result is a normal completion and result.[[Value]] is empty, then
LibJS: Make Value() default-construct the undefined value The special empty value (that we use for array holes, Optional<Value> when empty and a few other other placeholder/sentinel tasks) still exists, but you now create one via JS::js_special_empty_value() and check for it with Value::is_special_empty_value(). The main idea here is to make it very unlikely to accidentally create an unexpected special empty value.
2025-04-04 23:16:34 +02:00
if (result.type() == Completion::Type::Normal && result.value().is_special_empty_value()) {
LibJS: Remove redundant completion type check in ScriptEvaluation See editorial change to the ECMA-262 spec of: https://github.com/tc39/ecma262/commit/bc5b7fda5
2025-01-02 01:56:00 +13:00
// i. Set result to NormalCompletion(undefined).
result = normal_completion(js_undefined());
}
LibJS/Bytecode: Leave GlobalDeclarationInstantiation in C++ Don't try to implement this AO in bytecode. Instead, the bytecode Interpreter class now has a run() API with the same inputs as the AST interpreter. It sets up the necessary environments etc, including invoking the GlobalDeclarationInstantiation AO.
2023-06-15 12:36:57 +02:00
}
LibJS: Remove redundant completion type check in ScriptEvaluation See editorial change to the ECMA-262 spec of: https://github.com/tc39/ecma262/commit/bc5b7fda5
2025-01-02 01:56:00 +13:00
// 14. Suspend scriptContext and remove it from the execution context stack.
LibJS/Bytecode: Leave GlobalDeclarationInstantiation in C++ Don't try to implement this AO in bytecode. Instead, the bytecode Interpreter class now has a run() API with the same inputs as the AST interpreter. It sets up the necessary environments etc, including invoking the GlobalDeclarationInstantiation AO.
2023-06-15 12:36:57 +02:00
vm.pop_execution_context();
LibJS: Remove redundant completion type check in ScriptEvaluation See editorial change to the ECMA-262 spec of: https://github.com/tc39/ecma262/commit/bc5b7fda5
2025-01-02 01:56:00 +13:00
// 15. Assert: The execution context stack is not empty.
LibJS/Bytecode: Leave GlobalDeclarationInstantiation in C++ Don't try to implement this AO in bytecode. Instead, the bytecode Interpreter class now has a run() API with the same inputs as the AST interpreter. It sets up the necessary environments etc, including invoking the GlobalDeclarationInstantiation AO.
2023-06-15 12:36:57 +02:00
VERIFY(!vm.execution_context_stack().is_empty());
LibJS: Remove redundant completion type check in ScriptEvaluation See editorial change to the ECMA-262 spec of: https://github.com/tc39/ecma262/commit/bc5b7fda5
2025-01-02 01:56:00 +13:00
// FIXME: 16. Resume the context that is now on the top of the execution context stack as the running execution context.
LibJS/Bytecode: Leave GlobalDeclarationInstantiation in C++ Don't try to implement this AO in bytecode. Instead, the bytecode Interpreter class now has a run() API with the same inputs as the AST interpreter. It sets up the necessary environments etc, including invoking the GlobalDeclarationInstantiation AO.
2023-06-15 12:36:57 +02:00
vm.finish_execution_generation();
LibJS: Remove redundant completion type check in ScriptEvaluation See editorial change to the ECMA-262 spec of: https://github.com/tc39/ecma262/commit/bc5b7fda5
2025-01-02 01:56:00 +13:00
// 17. Return ? result.
LibJS/Bytecode: Leave GlobalDeclarationInstantiation in C++ Don't try to implement this AO in bytecode. Instead, the bytecode Interpreter class now has a run() API with the same inputs as the AST interpreter. It sets up the necessary environments etc, including invoking the GlobalDeclarationInstantiation AO.
2023-06-15 12:36:57 +02:00
if (result.is_abrupt()) {
VERIFY(result.type() == Completion::Type::Throw);
LibJS: Make Value() default-construct the undefined value The special empty value (that we use for array holes, Optional<Value> when empty and a few other other placeholder/sentinel tasks) still exists, but you now create one via JS::js_special_empty_value() and check for it with Value::is_special_empty_value(). The main idea here is to make it very unlikely to accidentally create an unexpected special empty value.
2025-04-04 23:16:34 +02:00
return result.release_error();
LibJS/Bytecode: Leave GlobalDeclarationInstantiation in C++ Don't try to implement this AO in bytecode. Instead, the bytecode Interpreter class now has a run() API with the same inputs as the AST interpreter. It sets up the necessary environments etc, including invoking the GlobalDeclarationInstantiation AO.
2023-06-15 12:36:57 +02:00
}
LibJS: Make Completion.[[Value]] non-optional Instead, just use js_undefined() whenever the [[Value]] field is unused. This avoids a whole bunch of presence checks.
2025-04-04 18:11:45 +02:00
return result.value();
LibJS/Bytecode: Leave GlobalDeclarationInstantiation in C++ Don't try to implement this AO in bytecode. Instead, the bytecode Interpreter class now has a run() API with the same inputs as the AST interpreter. It sets up the necessary environments etc, including invoking the GlobalDeclarationInstantiation AO.
2023-06-15 12:36:57 +02:00
}
ThrowCompletionOr<Value> Interpreter::run(SourceTextModule& module)
{
// FIXME: This is not a entry point as defined in the spec, but is convenient.
// To avoid work we use link_and_eval_module however that can already be
// dangerous if the vm loaded other modules.
auto& vm = this->vm();
TRY(vm.link_and_eval_module(Badge<Bytecode::Interpreter> {}, module));
vm.run_queued_promise_jobs();
vm.run_queued_finalization_registry_cleanup_jobs();
return js_undefined();
}
LibJS: Inline JS-to-JS calls in the bytecode interpreter dispatch loop Instead of recursing through 5 native stack frames per JS function call (execute_call -> internal_call -> ordinary_call_evaluate_body -> run_executable -> run_bytecode), handle Call and CallConstruct for normal ECMAScript functions directly in the dispatch loop. The fast path allocates the callee's execution context on the InterpreterStack, copies arguments, sets up the environment, and jumps to the callee's bytecode entry point. Return and End unwind inline frames by restoring the caller's state. Exception unwinding walks through inline frames to find handlers. The fast path code is kept in NEVER_INLINE helper functions (try_inline_call, try_inline_call_construct, pop_inline_frame) to minimize register pressure in the dispatch loop. handle_exception takes program_counter by value to avoid forcing it onto the stack. Reloading of bytecode/program_counter after frame switches is done inline at each call site via RELOAD_AND_GOTO_START to preserve a single dispatch entry point for optimal indirect branch prediction.
2026-03-04 10:33:29 +01:00
Interpreter::HandleExceptionResponse Interpreter::handle_exception(u32 program_counter, Value exception)
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
{
LibJS: Inline JS-to-JS calls in the bytecode interpreter dispatch loop Instead of recursing through 5 native stack frames per JS function call (execute_call -> internal_call -> ordinary_call_evaluate_body -> run_executable -> run_bytecode), handle Call and CallConstruct for normal ECMAScript functions directly in the dispatch loop. The fast path allocates the callee's execution context on the InterpreterStack, copies arguments, sets up the environment, and jumps to the callee's bytecode entry point. Return and End unwind inline frames by restoring the caller's state. Exception unwinding walks through inline frames to find handlers. The fast path code is kept in NEVER_INLINE helper functions (try_inline_call, try_inline_call_construct, pop_inline_frame) to minimize register pressure in the dispatch loop. handle_exception takes program_counter by value to avoid forcing it onto the stack. Reloading of bytecode/program_counter after frame switches is done inline at each call site via RELOAD_AND_GOTO_START to preserve a single dispatch entry point for optimal indirect branch prediction.
2026-03-04 10:33:29 +01:00
for (;;) {
auto handlers = current_executable().exception_handlers_for_offset(program_counter);
if (handlers.has_value()) {
reg(Register::exception()) = exception;
m_running_execution_context->program_counter = handlers->handler_offset;
return HandleExceptionResponse::ContinueInThisExecutable;
}
// If we're in an inline frame, unwind to the caller and try its handlers.
if (m_running_execution_context->caller_frame) {
auto* callee_frame = m_running_execution_context;
auto* caller_frame = callee_frame->caller_frame;
auto caller_pc = callee_frame->caller_return_pc;
LibJS: Use pop_execution_context() for inline frame unwinding This path will replace manual execution-context stack resizing with vm().pop_execution_context() in the inline unwind paths. Apply this in both exception unwinding and inline return handling so frame teardown consistently goes through the VM’s canonical pop logic, reducing the risk of execution-context stack desynchronization.
2026-03-05 23:23:34 +01:00
vm().pop_execution_context();
LibJS: Inline JS-to-JS calls in the bytecode interpreter dispatch loop Instead of recursing through 5 native stack frames per JS function call (execute_call -> internal_call -> ordinary_call_evaluate_body -> run_executable -> run_bytecode), handle Call and CallConstruct for normal ECMAScript functions directly in the dispatch loop. The fast path allocates the callee's execution context on the InterpreterStack, copies arguments, sets up the environment, and jumps to the callee's bytecode entry point. Return and End unwind inline frames by restoring the caller's state. Exception unwinding walks through inline frames to find handlers. The fast path code is kept in NEVER_INLINE helper functions (try_inline_call, try_inline_call_construct, pop_inline_frame) to minimize register pressure in the dispatch loop. handle_exception takes program_counter by value to avoid forcing it onto the stack. Reloading of bytecode/program_counter after frame switches is done inline at each call site via RELOAD_AND_GOTO_START to preserve a single dispatch entry point for optimal indirect branch prediction.
2026-03-04 10:33:29 +01:00
vm().interpreter_stack().deallocate(callee_frame);
m_running_execution_context = caller_frame;
// NB: caller_pc is the return address (one past the Call instruction).
// For handler lookup we need a PC inside the Call instruction,
// since the exception occurred during that call, not after it.
// Exception handler ranges use an exclusive end offset, so using
// caller_pc directly would miss a handler ending right at that address.
program_counter = caller_pc - 1;
continue;
}
reg(Register::exception()) = exception;
LibJS/Bytecode: Flatten bytecode to a contiguous representation Instead of keeping bytecode as a set of disjoint basic blocks on the malloc heap, bytecode is now a contiguous sequence of bytes(!) The transformation happens at the end of Bytecode::Generator::generate() and the only really hairy part is rerouting jump labels. This required solving a few problems: - The interpreter execution loop had to change quite a bit, since we were storing BasicBlock pointers all over the place, and control transfer was done by redirecting the interpreter's current block. - Exception handlers & finalizers are now stored per-bytecode-range in a side table in Executable. - The interpreter now has a plain program counter instead of a stream iterator. This actually makes error stack generation a bit nicer since we just have to deal with a number instead of reaching into the iterator. This yields a 25% performance improvement on this microbenchmark: for (let i = 0; i < 1_000_000; ++i) { } But basically everything gets faster. :^)
2024-05-06 06:44:08 +02:00
return HandleExceptionResponse::ExitFromExecutable;
}
LibJS: Inline JS-to-JS calls in the bytecode interpreter dispatch loop Instead of recursing through 5 native stack frames per JS function call (execute_call -> internal_call -> ordinary_call_evaluate_body -> run_executable -> run_bytecode), handle Call and CallConstruct for normal ECMAScript functions directly in the dispatch loop. The fast path allocates the callee's execution context on the InterpreterStack, copies arguments, sets up the environment, and jumps to the callee's bytecode entry point. Return and End unwind inline frames by restoring the caller's state. Exception unwinding walks through inline frames to find handlers. The fast path code is kept in NEVER_INLINE helper functions (try_inline_call, try_inline_call_construct, pop_inline_frame) to minimize register pressure in the dispatch loop. handle_exception takes program_counter by value to avoid forcing it onto the stack. Reloading of bytecode/program_counter after frame switches is done inline at each call site via RELOAD_AND_GOTO_START to preserve a single dispatch entry point for optimal indirect branch prediction.
2026-03-04 10:33:29 +01:00
}
ExecutionContext* Interpreter::push_inline_frame(
ECMAScriptFunctionObject& callee_function,
Executable& callee_executable,
ReadonlySpan<Operand> arguments,
u32 return_pc,
u32 dst_raw,
Value this_value,
Object* new_target,
bool is_construct)
{
auto& stack = vm().interpreter_stack();
u32 insn_argument_count = arguments.size();
size_t registers_and_locals_count = callee_executable.registers_and_locals_count;
size_t constants_count = callee_executable.constants.size();
size_t argument_count = max(insn_argument_count, static_cast<u32>(callee_function.formal_parameter_count()));
auto* callee_context = stack.allocate(registers_and_locals_count, constants_count, argument_count);
if (!callee_context) [[unlikely]]
return nullptr;
// Copy arguments from caller's registers into callee's argument slots.
auto* callee_argument_values = callee_context->arguments.data();
for (u32 i = 0; i < insn_argument_count; ++i)
callee_argument_values[i] = get(arguments[i]);
for (size_t i = insn_argument_count; i < argument_count; ++i)
callee_argument_values[i] = js_undefined();
callee_context->passed_argument_count = insn_argument_count;
// Set up caller linkage so Return can restore the caller frame.
callee_context->caller_frame = m_running_execution_context;
callee_context->caller_executable = m_running_execution_context->executable;
callee_context->caller_dst_raw = dst_raw;
callee_context->caller_return_pc = return_pc;
callee_context->caller_is_construct = is_construct;
// Inlined PrepareForOrdinaryCall (avoids function call overhead on hot path).
callee_context->function = &callee_function;
callee_context->realm = callee_function.realm();
callee_context->script_or_module = callee_function.m_script_or_module;
if (callee_function.function_environment_needed()) {
auto local_environment = new_function_environment(callee_function, new_target);
local_environment->ensure_capacity(callee_function.shared_data().m_function_environment_bindings_count);
callee_context->lexical_environment = local_environment;
callee_context->variable_environment = local_environment;
} else {
callee_context->lexical_environment = callee_function.environment();
callee_context->variable_environment = callee_function.environment();
}
callee_context->private_environment = callee_function.m_private_environment;
// Fast-path push onto execution context stack (avoids Vector::append growth check preventing inlining).
auto& ec_stack = vm().execution_context_stack();
if (ec_stack.size() < ec_stack.capacity()) [[likely]]
ec_stack.unchecked_append(callee_context);
else
ec_stack.append(callee_context);
// Bind this if the function uses it.
if (callee_function.uses_this())
callee_function.ordinary_call_bind_this(vm(), *callee_context, this_value);
// Set up execution context fields that run_executable normally does.
// NB: We must use the callee's realm (not the caller's) for global_object
// and global_declarative_environment, since the caller's realm may differ
// in cross-realm calls (e.g. iframe <-> parent).
callee_context->executable = callee_executable;
// Copy constants (memcpy avoids aliasing issues with the scalar loop).
auto* values = callee_context->registers_and_constants_and_locals_and_arguments();
if (auto count = callee_executable.constants.size())
memcpy(values + callee_executable.registers_and_locals_count,
callee_executable.constants.data(),
count * sizeof(Value));
// Set this value register.
values[Register::this_value().index()] = callee_context->this_value.value_or(js_special_empty_value());
return callee_context;
}
NEVER_INLINE bool Interpreter::try_inline_call(Instruction const& insn, u32 current_pc)
{
auto& instruction = static_cast<Op::Call const&>(insn);
auto callee = get(instruction.callee());
if (!callee.is_object())
return false;
auto& callee_object = callee.as_object();
if (!is<ECMAScriptFunctionObject>(callee_object))
return false;
auto& callee_function = static_cast<ECMAScriptFunctionObject&>(callee_object);
if (callee_function.kind() != FunctionKind::Normal
|| callee_function.is_class_constructor()
|| !callee_function.bytecode_executable())
return false;
u32 return_pc = current_pc + instruction.length();
auto* callee_context = push_inline_frame(
callee_function, *callee_function.bytecode_executable(),
instruction.arguments(), return_pc, instruction.dst().raw(),
get(instruction.this_value()), nullptr, false);
if (!callee_context) [[unlikely]]
return false;
m_running_execution_context = callee_context;
return true;
}
NEVER_INLINE bool Interpreter::try_inline_call_construct(Instruction const& insn, u32 current_pc)
{
auto& instruction = static_cast<Op::CallConstruct const&>(insn);
auto callee = get(instruction.callee());
if (!callee.is_object())
return false;
auto& callee_object = callee.as_object();
if (!is<ECMAScriptFunctionObject>(callee_object))
return false;
auto& callee_function = static_cast<ECMAScriptFunctionObject&>(callee_object);
if (!callee_function.has_constructor()
|| callee_function.constructor_kind() != ConstructorKind::Base
|| !callee_function.bytecode_executable())
return false;
// OrdinaryCreateFromConstructor: create the this object.
auto prototype_or_error = get_prototype_from_constructor(vm(), callee_function, &Intrinsics::object_prototype);
if (prototype_or_error.is_error()) [[unlikely]]
return false;
auto this_argument = Object::create(realm(), prototype_or_error.release_value());
u32 return_pc = current_pc + instruction.length();
auto* callee_context = push_inline_frame(
callee_function, *callee_function.bytecode_executable(),
instruction.arguments(), return_pc, instruction.dst().raw(),
this_argument, &callee_function, true);
if (!callee_context) [[unlikely]]
return false;
// Ensure this_value is set for construct return semantics.
if (!callee_context->this_value.has_value())
callee_context->this_value = Value(this_argument);
// InitializeInstanceElements (can throw).
auto init_result = this_argument->initialize_instance_elements(callee_function);
if (init_result.is_throw_completion()) [[unlikely]] {
vm().pop_execution_context();
vm().interpreter_stack().deallocate(callee_context);
return false;
}
m_running_execution_context = callee_context;
return true;
}
NEVER_INLINE void Interpreter::pop_inline_frame(Value return_value)
{
auto* callee_frame = m_running_execution_context;
auto* caller_frame = callee_frame->caller_frame;
auto caller_dst_raw = callee_frame->caller_dst_raw;
auto caller_pc = callee_frame->caller_return_pc;
// For base constructor calls, apply construct return semantics.
if (callee_frame->caller_is_construct && !return_value.is_object())
return_value = callee_frame->this_value.value();
LibJS: Use pop_execution_context() for inline frame unwinding This path will replace manual execution-context stack resizing with vm().pop_execution_context() in the inline unwind paths. Apply this in both exception unwinding and inline return handling so frame teardown consistently goes through the VM’s canonical pop logic, reducing the risk of execution-context stack desynchronization.
2026-03-05 23:23:34 +01:00
vm().pop_execution_context();
LibJS: Inline JS-to-JS calls in the bytecode interpreter dispatch loop Instead of recursing through 5 native stack frames per JS function call (execute_call -> internal_call -> ordinary_call_evaluate_body -> run_executable -> run_bytecode), handle Call and CallConstruct for normal ECMAScript functions directly in the dispatch loop. The fast path allocates the callee's execution context on the InterpreterStack, copies arguments, sets up the environment, and jumps to the callee's bytecode entry point. Return and End unwind inline frames by restoring the caller's state. Exception unwinding walks through inline frames to find handlers. The fast path code is kept in NEVER_INLINE helper functions (try_inline_call, try_inline_call_construct, pop_inline_frame) to minimize register pressure in the dispatch loop. handle_exception takes program_counter by value to avoid forcing it onto the stack. Reloading of bytecode/program_counter after frame switches is done inline at each call site via RELOAD_AND_GOTO_START to preserve a single dispatch entry point for optimal indirect branch prediction.
2026-03-04 10:33:29 +01:00
vm().interpreter_stack().deallocate(callee_frame);
m_running_execution_context = caller_frame;
caller_frame->program_counter = caller_pc;
caller_frame->registers_and_constants_and_locals_and_arguments()[caller_dst_raw] = return_value;
vm().finish_execution_generation();
LibJS/Bytecode: Flatten bytecode to a contiguous representation Instead of keeping bytecode as a set of disjoint basic blocks on the malloc heap, bytecode is now a contiguous sequence of bytes(!) The transformation happens at the end of Bytecode::Generator::generate() and the only really hairy part is rerouting jump labels. This required solving a few problems: - The interpreter execution loop had to change quite a bit, since we were storing BasicBlock pointers all over the place, and control transfer was done by redirecting the interpreter's current block. - Exception handlers & finalizers are now stored per-bytecode-range in a side table in Executable. - The interpreter now has a plain program counter instead of a stream iterator. This actually makes error stack generation a bit nicer since we just have to deal with a number instead of reaching into the iterator. This yields a 25% performance improvement on this microbenchmark: for (let i = 0; i < 1_000_000; ++i) { } But basically everything gets faster. :^)
2024-05-06 06:44:08 +02:00
}
LibJS: Remove FLATTEN from bytecode interpreter This doesn't appear to improve performance on my machine anymore. It also very modestly reduces interpreter size.
2025-12-04 11:25:57 +01:00
void Interpreter::run_bytecode(size_t entry_point)
LibJS/Bytecode: Flatten bytecode to a contiguous representation Instead of keeping bytecode as a set of disjoint basic blocks on the malloc heap, bytecode is now a contiguous sequence of bytes(!) The transformation happens at the end of Bytecode::Generator::generate() and the only really hairy part is rerouting jump labels. This required solving a few problems: - The interpreter execution loop had to change quite a bit, since we were storing BasicBlock pointers all over the place, and control transfer was done by redirecting the interpreter's current block. - Exception handlers & finalizers are now stored per-bytecode-range in a side table in Executable. - The interpreter now has a plain program counter instead of a stream iterator. This actually makes error stack generation a bit nicer since we just have to deal with a number instead of reaching into the iterator. This yields a 25% performance improvement on this microbenchmark: for (let i = 0; i < 1_000_000; ++i) { } But basically everything gets faster. :^)
2024-05-06 06:44:08 +02:00
{
LibJS+LibWeb: Use InterpreterStack for all execution context allocation Replace alloca-based execution context allocation with InterpreterStack bump allocation across all call sites: bytecode call instructions, AbstractOperations call/construct, script evaluation, module evaluation, and LibWeb module script evaluation. Also replace the native stack space check with an InterpreterStack exhaustion check, and remove the now-unused alloca macros from ExecutionContext.h.
2026-03-04 10:32:01 +01:00
if (vm().interpreter_stack().is_exhausted() || vm().did_reach_stack_space_limit()) [[unlikely]] {
LibJS: Make Completion.[[Value]] non-optional Instead, just use js_undefined() whenever the [[Value]] field is unused. This avoids a whole bunch of presence checks.
2025-04-04 18:11:45 +02:00
reg(Register::exception()) = vm().throw_completion<InternalError>(ErrorType::CallStackSizeExceeded).value();
LibJS/Bytecode: Do a stack check when entering run_bytecode() If we don't have enough stack space, throw an exception while we still can, and give the caller a chance to recover. This particular problem will go away once we make calls non-recursive.
2024-05-07 07:50:19 +02:00
return;
}
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
static bool const use_cpp_interpreter = []() {
auto const* env = getenv("LIBJS_USE_CPP_INTERPRETER");
return env && env[0] == '1';
}();
if (!use_cpp_interpreter && AsmInterpreter::is_available()) {
AsmInterpreter::run(*this, entry_point);
return;
}
LibJS: Inline JS-to-JS calls in the bytecode interpreter dispatch loop Instead of recursing through 5 native stack frames per JS function call (execute_call -> internal_call -> ordinary_call_evaluate_body -> run_executable -> run_bytecode), handle Call and CallConstruct for normal ECMAScript functions directly in the dispatch loop. The fast path allocates the callee's execution context on the InterpreterStack, copies arguments, sets up the environment, and jumps to the callee's bytecode entry point. Return and End unwind inline frames by restoring the caller's state. Exception unwinding walks through inline frames to find handlers. The fast path code is kept in NEVER_INLINE helper functions (try_inline_call, try_inline_call_construct, pop_inline_frame) to minimize register pressure in the dispatch loop. handle_exception takes program_counter by value to avoid forcing it onto the stack. Reloading of bytecode/program_counter after frame switches is done inline at each call site via RELOAD_AND_GOTO_START to preserve a single dispatch entry point for optimal indirect branch prediction.
2026-03-04 10:33:29 +01:00
u8 const* bytecode;
u32 program_counter;
LibJS/Bytecode: Flatten bytecode to a contiguous representation Instead of keeping bytecode as a set of disjoint basic blocks on the malloc heap, bytecode is now a contiguous sequence of bytes(!) The transformation happens at the end of Bytecode::Generator::generate() and the only really hairy part is rerouting jump labels. This required solving a few problems: - The interpreter execution loop had to change quite a bit, since we were storing BasicBlock pointers all over the place, and control transfer was done by redirecting the interpreter's current block. - Exception handlers & finalizers are now stored per-bytecode-range in a side table in Executable. - The interpreter now has a plain program counter instead of a stream iterator. This actually makes error stack generation a bit nicer since we just have to deal with a number instead of reaching into the iterator. This yields a 25% performance improvement on this microbenchmark: for (let i = 0; i < 1_000_000; ++i) { } But basically everything gets faster. :^)
2024-05-06 06:44:08 +02:00
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
// Declare a lookup table for computed goto with each of the `handle_*` labels
// to avoid the overhead of a switch statement.
// This is a GCC extension, but it's also supported by Clang.
static void* const bytecode_dispatch_table[] = {
#define SET_UP_LABEL(name) &&handle_##name,
ENUMERATE_BYTECODE_OPS(SET_UP_LABEL)
};
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 15:13:31 +02:00
#undef SET_UP_LABEL
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
#define DISPATCH_NEXT(name) \
do { \
if constexpr (Op::name::IsVariableLength) \
Revert "LibJS: Avoid calling generic Instruction::length() during dispatch" This reverts commit 8f2ee01e6fb41b85f8966f0112034d95ce25f88e. Speculative revert, as this appears to severely regress performance on our JS benchmark runner.
2025-04-03 15:09:49 +02:00
program_counter += instruction.length(); \
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
else \
program_counter += sizeof(Op::name); \
LibJS: Inline JS-to-JS calls in the bytecode interpreter dispatch loop Instead of recursing through 5 native stack frames per JS function call (execute_call -> internal_call -> ordinary_call_evaluate_body -> run_executable -> run_bytecode), handle Call and CallConstruct for normal ECMAScript functions directly in the dispatch loop. The fast path allocates the callee's execution context on the InterpreterStack, copies arguments, sets up the environment, and jumps to the callee's bytecode entry point. Return and End unwind inline frames by restoring the caller's state. Exception unwinding walks through inline frames to find handlers. The fast path code is kept in NEVER_INLINE helper functions (try_inline_call, try_inline_call_construct, pop_inline_frame) to minimize register pressure in the dispatch loop. handle_exception takes program_counter by value to avoid forcing it onto the stack. Reloading of bytecode/program_counter after frame switches is done inline at each call site via RELOAD_AND_GOTO_START to preserve a single dispatch entry point for optimal indirect branch prediction.
2026-03-04 10:33:29 +01:00
m_running_execution_context->program_counter = program_counter; \
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
auto& next_instruction = *reinterpret_cast<Instruction const*>(&bytecode[program_counter]); \
goto* bytecode_dispatch_table[static_cast<size_t>(next_instruction.type())]; \
} while (0)
LibJS: Inline JS-to-JS calls in the bytecode interpreter dispatch loop Instead of recursing through 5 native stack frames per JS function call (execute_call -> internal_call -> ordinary_call_evaluate_body -> run_executable -> run_bytecode), handle Call and CallConstruct for normal ECMAScript functions directly in the dispatch loop. The fast path allocates the callee's execution context on the InterpreterStack, copies arguments, sets up the environment, and jumps to the callee's bytecode entry point. Return and End unwind inline frames by restoring the caller's state. Exception unwinding walks through inline frames to find handlers. The fast path code is kept in NEVER_INLINE helper functions (try_inline_call, try_inline_call_construct, pop_inline_frame) to minimize register pressure in the dispatch loop. handle_exception takes program_counter by value to avoid forcing it onto the stack. Reloading of bytecode/program_counter after frame switches is done inline at each call site via RELOAD_AND_GOTO_START to preserve a single dispatch entry point for optimal indirect branch prediction.
2026-03-04 10:33:29 +01:00
// Reload bytecode and program_counter from the execution context after
// operations that may have changed the current executable (handle_exception
// unwinding inline frames, try_inline_call, pop_inline_frame).
#define RELOAD_AND_GOTO_START() \
do { \
bytecode = m_running_execution_context->executable->bytecode.data(); \
program_counter = m_running_execution_context->program_counter; \
goto start; \
} while (0)
bytecode = current_executable().bytecode.data();
program_counter = entry_point;
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
for (;;) {
LibJS: Use `goto` instead of `bool will_jump` in interpreter loop This is honestly less spaghetti-ish.
2023-09-26 16:45:55 +02:00
start:
LibJS: Inline JS-to-JS calls in the bytecode interpreter dispatch loop Instead of recursing through 5 native stack frames per JS function call (execute_call -> internal_call -> ordinary_call_evaluate_body -> run_executable -> run_bytecode), handle Call and CallConstruct for normal ECMAScript functions directly in the dispatch loop. The fast path allocates the callee's execution context on the InterpreterStack, copies arguments, sets up the environment, and jumps to the callee's bytecode entry point. Return and End unwind inline frames by restoring the caller's state. Exception unwinding walks through inline frames to find handlers. The fast path code is kept in NEVER_INLINE helper functions (try_inline_call, try_inline_call_construct, pop_inline_frame) to minimize register pressure in the dispatch loop. handle_exception takes program_counter by value to avoid forcing it onto the stack. Reloading of bytecode/program_counter after frame switches is done inline at each call site via RELOAD_AND_GOTO_START to preserve a single dispatch entry point for optimal indirect branch prediction.
2026-03-04 10:33:29 +01:00
m_running_execution_context->program_counter = program_counter;
LibJS/Bytecode: Flatten bytecode to a contiguous representation Instead of keeping bytecode as a set of disjoint basic blocks on the malloc heap, bytecode is now a contiguous sequence of bytes(!) The transformation happens at the end of Bytecode::Generator::generate() and the only really hairy part is rerouting jump labels. This required solving a few problems: - The interpreter execution loop had to change quite a bit, since we were storing BasicBlock pointers all over the place, and control transfer was done by redirecting the interpreter's current block. - Exception handlers & finalizers are now stored per-bytecode-range in a side table in Executable. - The interpreter now has a plain program counter instead of a stream iterator. This actually makes error stack generation a bit nicer since we just have to deal with a number instead of reaching into the iterator. This yields a 25% performance improvement on this microbenchmark: for (let i = 0; i < 1_000_000; ++i) { } But basically everything gets faster. :^)
2024-05-06 06:44:08 +02:00
for (;;) {
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
goto* bytecode_dispatch_table[static_cast<size_t>((*reinterpret_cast<Instruction const*>(&bytecode[program_counter])).type())];
LibJS: Return early from Interpreter on unhandled exception If we don't have a local unwind context to handle the exception, we can just return right away. This allows us to remove one check from the inner loop.
2023-09-26 17:14:59 +02:00
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
handle_Mov: {
auto& instruction = *reinterpret_cast<Op::Mov const*>(&bytecode[program_counter]);
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
set(instruction.dst(), get(instruction.src()));
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
DISPATCH_NEXT(Mov);
}
handle_End: {
auto& instruction = *reinterpret_cast<Op::End const*>(&bytecode[program_counter]);
LibJS: Coerce empty completion to "undefined" early in Interpreter Instead of always checking if we're about to return an empty completion value in Interpreter::run_executable(), we now coerce empty completions to the undefined value earlier instead. This simplifies the most common path through run_executable(), giving us a small speedup.
2025-10-31 21:10:51 +01:00
auto value = get(instruction.value());
if (value.is_special_empty_value())
value = js_undefined();
LibJS: Inline JS-to-JS calls in the bytecode interpreter dispatch loop Instead of recursing through 5 native stack frames per JS function call (execute_call -> internal_call -> ordinary_call_evaluate_body -> run_executable -> run_bytecode), handle Call and CallConstruct for normal ECMAScript functions directly in the dispatch loop. The fast path allocates the callee's execution context on the InterpreterStack, copies arguments, sets up the environment, and jumps to the callee's bytecode entry point. Return and End unwind inline frames by restoring the caller's state. Exception unwinding walks through inline frames to find handlers. The fast path code is kept in NEVER_INLINE helper functions (try_inline_call, try_inline_call_construct, pop_inline_frame) to minimize register pressure in the dispatch loop. handle_exception takes program_counter by value to avoid forcing it onto the stack. Reloading of bytecode/program_counter after frame switches is done inline at each call site via RELOAD_AND_GOTO_START to preserve a single dispatch entry point for optimal indirect branch prediction.
2026-03-04 10:33:29 +01:00
if (m_running_execution_context->caller_frame) {
pop_inline_frame(value);
RELOAD_AND_GOTO_START();
}
LibJS: Coerce empty completion to "undefined" early in Interpreter Instead of always checking if we're about to return an empty completion value in Interpreter::run_executable(), we now coerce empty completions to the undefined value earlier instead. This simplifies the most common path through run_executable(), giving us a small speedup.
2025-10-31 21:10:51 +01:00
reg(Register::return_value()) = value;
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
return;
}
handle_Jump: {
auto& instruction = *reinterpret_cast<Op::Jump const*>(&bytecode[program_counter]);
program_counter = instruction.target().address();
goto start;
}
handle_JumpIf: {
auto& instruction = *reinterpret_cast<Op::JumpIf const*>(&bytecode[program_counter]);
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
if (get(instruction.condition()).to_boolean())
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
program_counter = instruction.true_target().address();
else
program_counter = instruction.false_target().address();
goto start;
}
handle_JumpTrue: {
auto& instruction = *reinterpret_cast<Op::JumpTrue const*>(&bytecode[program_counter]);
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
if (get(instruction.condition()).to_boolean()) {
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
program_counter = instruction.target().address();
LibJS/Bytecode: Unroll the bytecode interpreter This commit adds a HANDLE_INSTRUCTION macro that expands to everything needed to handle a single instruction (invoking the handler function, checking for exceptions, and advancing the program counter). This gives a ~15% speed-up on a for loop microbenchmark, and makes basically everything faster.
2024-05-06 10:42:52 +02:00
goto start;
LibJS/Bytecode: Turn JumpIf condition,@a,@next into JumpTrue/JumpFalse If one of the jump targets is the very next block, we can convert the jump instruction into a smaller JumpTrue or JumpFalse.
2024-05-06 10:15:17 +02:00
}
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
DISPATCH_NEXT(JumpTrue);
}
handle_JumpFalse: {
auto& instruction = *reinterpret_cast<Op::JumpFalse const*>(&bytecode[program_counter]);
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
if (!get(instruction.condition()).to_boolean()) {
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
program_counter = instruction.target().address();
LibJS/Bytecode: Unroll the bytecode interpreter This commit adds a HANDLE_INSTRUCTION macro that expands to everything needed to handle a single instruction (invoking the handler function, checking for exceptions, and advancing the program counter). This gives a ~15% speed-up on a for loop microbenchmark, and makes basically everything faster.
2024-05-06 10:42:52 +02:00
goto start;
LibJS/Bytecode: Turn JumpIf condition,@a,@next into JumpTrue/JumpFalse If one of the jump targets is the very next block, we can convert the jump instruction into a smaller JumpTrue or JumpFalse.
2024-05-06 10:15:17 +02:00
}
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
DISPATCH_NEXT(JumpFalse);
}
handle_JumpNullish: {
auto& instruction = *reinterpret_cast<Op::JumpNullish const*>(&bytecode[program_counter]);
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
if (get(instruction.condition()).is_nullish())
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
program_counter = instruction.true_target().address();
else
program_counter = instruction.false_target().address();
goto start;
}
LibJS/Bytecode: Add fast paths for compare-and-jump with 2 numbers When comparing two numbers, we can avoid a lot of implicit type conversion nonsense and go straight to comparison, saving time in the most common case.
2024-05-13 09:23:53 +02:00
#define HANDLE_COMPARISON_OP(op_TitleCase, op_snake_case, numeric_operator) \
LibJS/Bytecode: Grab at ThrowCompletionOr errors directly The interpreter can now grab at the error value directly instead of instantiating a temporary Completion to hold it.
2024-05-10 11:22:27 +02:00
handle_Jump##op_TitleCase: \
{ \
auto& instruction = *reinterpret_cast<Op::Jump##op_TitleCase const*>(&bytecode[program_counter]); \
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto lhs = get(instruction.lhs()); \
auto rhs = get(instruction.rhs()); \
LibJS: Mark more interpreter fast paths [[likely]] Let's assume arithmetic and comparison operators are mostly being used on numbers.
2025-12-04 22:26:22 +01:00
if (lhs.is_number() && rhs.is_number()) [[likely]] { \
LibJS/Bytecode: Add fast paths for compare-and-jump with 2 numbers When comparing two numbers, we can avoid a lot of implicit type conversion nonsense and go straight to comparison, saving time in the most common case.
2024-05-13 09:23:53 +02:00
bool result; \
if (lhs.is_int32() && rhs.is_int32()) { \
result = lhs.as_i32() numeric_operator rhs.as_i32(); \
} else { \
result = lhs.as_double() numeric_operator rhs.as_double(); \
} \
program_counter = result ? instruction.true_target().address() : instruction.false_target().address(); \
goto start; \
} \
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto result = op_snake_case(vm(), get(instruction.lhs()), get(instruction.rhs())); \
LibJS: Mark exception-handling paths with [[unlikely]] in interpreter This appears actually helpful and consistently makes all benchmarks slightly faster on my machine.
2025-04-06 02:32:04 +02:00
if (result.is_error()) [[unlikely]] { \
LibJS/Bytecode: Grab at ThrowCompletionOr errors directly The interpreter can now grab at the error value directly instead of instantiating a temporary Completion to hold it.
2024-05-10 11:22:27 +02:00
if (handle_exception(program_counter, result.error_value()) == HandleExceptionResponse::ExitFromExecutable) \
return; \
LibJS: Inline JS-to-JS calls in the bytecode interpreter dispatch loop Instead of recursing through 5 native stack frames per JS function call (execute_call -> internal_call -> ordinary_call_evaluate_body -> run_executable -> run_bytecode), handle Call and CallConstruct for normal ECMAScript functions directly in the dispatch loop. The fast path allocates the callee's execution context on the InterpreterStack, copies arguments, sets up the environment, and jumps to the callee's bytecode entry point. Return and End unwind inline frames by restoring the caller's state. Exception unwinding walks through inline frames to find handlers. The fast path code is kept in NEVER_INLINE helper functions (try_inline_call, try_inline_call_construct, pop_inline_frame) to minimize register pressure in the dispatch loop. handle_exception takes program_counter by value to avoid forcing it onto the stack. Reloading of bytecode/program_counter after frame switches is done inline at each call site via RELOAD_AND_GOTO_START to preserve a single dispatch entry point for optimal indirect branch prediction.
2026-03-04 10:33:29 +01:00
RELOAD_AND_GOTO_START(); \
LibJS/Bytecode: Grab at ThrowCompletionOr errors directly The interpreter can now grab at the error value directly instead of instantiating a temporary Completion to hold it.
2024-05-10 11:22:27 +02:00
} \
LibJS: Avoid roundtrip through Value for comparison bytecode evaluation 1.1x speedup on strictly-equals-object.js
2025-05-08 15:19:35 +12:00
if (result.value()) \
LibJS/Bytecode: Grab at ThrowCompletionOr errors directly The interpreter can now grab at the error value directly instead of instantiating a temporary Completion to hold it.
2024-05-10 11:22:27 +02:00
program_counter = instruction.true_target().address(); \
else \
program_counter = instruction.false_target().address(); \
goto start; \
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 15:13:31 +02:00
}
JS_ENUMERATE_COMPARISON_OPS(HANDLE_COMPARISON_OP)
#undef HANDLE_COMPARISON_OP
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
handle_JumpUndefined: {
auto& instruction = *reinterpret_cast<Op::JumpUndefined const*>(&bytecode[program_counter]);
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
if (get(instruction.condition()).is_undefined())
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
program_counter = instruction.true_target().address();
else
program_counter = instruction.false_target().address();
goto start;
}
LibJS/Bytecode: Grab at ThrowCompletionOr errors directly The interpreter can now grab at the error value directly instead of instantiating a temporary Completion to hold it.
2024-05-10 11:22:27 +02:00
#define HANDLE_INSTRUCTION(name) \
handle_##name: \
{ \
auto& instruction = *reinterpret_cast<Op::name const*>(&bytecode[program_counter]); \
{ \
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto result = instruction.execute_impl(*this); \
LibJS: Mark exception-handling paths with [[unlikely]] in interpreter This appears actually helpful and consistently makes all benchmarks slightly faster on my machine.
2025-04-06 02:32:04 +02:00
if (result.is_error()) [[unlikely]] { \
LibJS/Bytecode: Grab at ThrowCompletionOr errors directly The interpreter can now grab at the error value directly instead of instantiating a temporary Completion to hold it.
2024-05-10 11:22:27 +02:00
if (handle_exception(program_counter, result.error_value()) == HandleExceptionResponse::ExitFromExecutable) \
return; \
LibJS: Inline JS-to-JS calls in the bytecode interpreter dispatch loop Instead of recursing through 5 native stack frames per JS function call (execute_call -> internal_call -> ordinary_call_evaluate_body -> run_executable -> run_bytecode), handle Call and CallConstruct for normal ECMAScript functions directly in the dispatch loop. The fast path allocates the callee's execution context on the InterpreterStack, copies arguments, sets up the environment, and jumps to the callee's bytecode entry point. Return and End unwind inline frames by restoring the caller's state. Exception unwinding walks through inline frames to find handlers. The fast path code is kept in NEVER_INLINE helper functions (try_inline_call, try_inline_call_construct, pop_inline_frame) to minimize register pressure in the dispatch loop. handle_exception takes program_counter by value to avoid forcing it onto the stack. Reloading of bytecode/program_counter after frame switches is done inline at each call site via RELOAD_AND_GOTO_START to preserve a single dispatch entry point for optimal indirect branch prediction.
2026-03-04 10:33:29 +01:00
RELOAD_AND_GOTO_START(); \
LibJS/Bytecode: Grab at ThrowCompletionOr errors directly The interpreter can now grab at the error value directly instead of instantiating a temporary Completion to hold it.
2024-05-10 11:22:27 +02:00
} \
} \
DISPATCH_NEXT(name); \
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
}
LibJS/Bytecode: Skip unnecessary exception checks in interpreter Many opcodes cannot ever throw an exception, so we can just avoid checking it after executing them.
2024-05-09 15:24:34 +02:00
#define HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(name) \
handle_##name: \
{ \
auto& instruction = *reinterpret_cast<Op::name const*>(&bytecode[program_counter]); \
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
instruction.execute_impl(*this); \
LibJS/Bytecode: Skip unnecessary exception checks in interpreter Many opcodes cannot ever throw an exception, so we can just avoid checking it after executing them.
2024-05-09 15:24:34 +02:00
DISPATCH_NEXT(name); \
}
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
HANDLE_INSTRUCTION(Add);
LibJS: Stop using execute_ast_node() for class property evaluation Instead, generate bytecode to execute their AST nodes and save the resulting operands inside the NewClass instruction. Moving property expression evaluation to happen before NewClass execution also moves along creation of new private environment and its population with private members (private members should be visible during property evaluation). Before: - NewClass After: - CreatePrivateEnvironment - AddPrivateName - ... - AddPrivateName - NewClass - LeavePrivateEnvironment
2024-05-11 22:54:41 +00:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(AddPrivateName);
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
HANDLE_INSTRUCTION(ArrayAppend);
HANDLE_INSTRUCTION(BitwiseAnd);
HANDLE_INSTRUCTION(BitwiseNot);
HANDLE_INSTRUCTION(BitwiseOr);
LibJS: Add dedicated bytecode instruction for x|0 (ToInt32) This operation is a very common technique to force a value to become a 32-bit integer.
2025-12-15 00:14:15 -06:00
HANDLE_INSTRUCTION(ToInt32);
LibJS: Reduce number of template literal op codes There is no need to concat empty string literals when building template literals. Now strings will only be concatenated if they need to be. To handle the edge case where the first segment is not a string literal, a new `ToString` op code has been added to ensure the value is a string concatenating more strings. In addition, basic const folding is now supported for template literal constants (templates with no interpolated values), which is commonly used for multi-line string constants.
2026-01-22 17:23:19 -08:00
HANDLE_INSTRUCTION(ToString);
LibJS: Fix evaluation order of computed property keys in object literals The spec for PropertyDefinitionEvaluation requires that when evaluating a property definition with a computed key (PropertyDefinition : PropertyName : AssignmentExpression), the PropertyName is fully evaluated (including ToPropertyKey, which calls ToPrimitive) before the value's AssignmentExpression is evaluated. Our bytecode compiler was evaluating the key expression first, then the value expression, and only performing ToPropertyKey later inside PutByValue at runtime. This meant user-observable side effects from ToPrimitive (such as calling Symbol.toPrimitive or toString on the key object) would fire after the value expression had already been evaluated. Fix this by using a new ToPrimitiveWithStringHint instruction that performs ToPrimitive with string hint(!), and emitting it between the key and value evaluations in ObjectExpression codegen. After ToPrimitive, the key is already a primitive, so the subsequent ToPropertyKey inside PutByValue becomes a no-op from the perspective of user-observable side effects. Also update an existing test that was asserting the old (incorrect) evaluation order, and add comprehensive new tests for computed property key evaluation order.
2026-02-08 12:32:38 +01:00
HANDLE_INSTRUCTION(ToPrimitiveWithStringHint);
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
HANDLE_INSTRUCTION(BitwiseXor);
LibJS: Inline JS-to-JS calls in the bytecode interpreter dispatch loop Instead of recursing through 5 native stack frames per JS function call (execute_call -> internal_call -> ordinary_call_evaluate_body -> run_executable -> run_bytecode), handle Call and CallConstruct for normal ECMAScript functions directly in the dispatch loop. The fast path allocates the callee's execution context on the InterpreterStack, copies arguments, sets up the environment, and jumps to the callee's bytecode entry point. Return and End unwind inline frames by restoring the caller's state. Exception unwinding walks through inline frames to find handlers. The fast path code is kept in NEVER_INLINE helper functions (try_inline_call, try_inline_call_construct, pop_inline_frame) to minimize register pressure in the dispatch loop. handle_exception takes program_counter by value to avoid forcing it onto the stack. Reloading of bytecode/program_counter after frame switches is done inline at each call site via RELOAD_AND_GOTO_START to preserve a single dispatch entry point for optimal indirect branch prediction.
2026-03-04 10:33:29 +01:00
handle_Call: {
auto& instruction = *reinterpret_cast<Op::Call const*>(&bytecode[program_counter]);
if (try_inline_call(instruction, program_counter))
RELOAD_AND_GOTO_START();
auto result = instruction.execute_impl(*this);
if (result.is_error()) [[unlikely]] {
if (handle_exception(program_counter, result.error_value()) == HandleExceptionResponse::ExitFromExecutable)
return;
RELOAD_AND_GOTO_START();
}
DISPATCH_NEXT(Call);
}
LibJS: Split `Call` Instruction by `CallType` Instead of branching on the `CallType` at runtime in a hot instruction like `Call`, lets emit separate instructions for each call type during codegen.
2024-10-31 22:47:30 +01:00
HANDLE_INSTRUCTION(CallBuiltin);
LibJS: Inline JS-to-JS calls in the bytecode interpreter dispatch loop Instead of recursing through 5 native stack frames per JS function call (execute_call -> internal_call -> ordinary_call_evaluate_body -> run_executable -> run_bytecode), handle Call and CallConstruct for normal ECMAScript functions directly in the dispatch loop. The fast path allocates the callee's execution context on the InterpreterStack, copies arguments, sets up the environment, and jumps to the callee's bytecode entry point. Return and End unwind inline frames by restoring the caller's state. Exception unwinding walks through inline frames to find handlers. The fast path code is kept in NEVER_INLINE helper functions (try_inline_call, try_inline_call_construct, pop_inline_frame) to minimize register pressure in the dispatch loop. handle_exception takes program_counter by value to avoid forcing it onto the stack. Reloading of bytecode/program_counter after frame switches is done inline at each call site via RELOAD_AND_GOTO_START to preserve a single dispatch entry point for optimal indirect branch prediction.
2026-03-04 10:33:29 +01:00
handle_CallConstruct: {
auto& instruction = *reinterpret_cast<Op::CallConstruct const*>(&bytecode[program_counter]);
if (try_inline_call_construct(instruction, program_counter))
RELOAD_AND_GOTO_START();
auto result = instruction.execute_impl(*this);
if (result.is_error()) [[unlikely]] {
if (handle_exception(program_counter, result.error_value()) == HandleExceptionResponse::ExitFromExecutable)
return;
RELOAD_AND_GOTO_START();
}
DISPATCH_NEXT(CallConstruct);
}
LibJS: Allocate context up front when calling with argument array This necessitated splitting CallWithArgumentArray into three variants, one for each call type (call, construct and direct eval).
2025-08-30 11:00:54 +02:00
HANDLE_INSTRUCTION(CallConstructWithArgumentArray);
LibJS: Split `Call` Instruction by `CallType` Instead of branching on the `CallType` at runtime in a hot instruction like `Call`, lets emit separate instructions for each call type during codegen.
2024-10-31 22:47:30 +01:00
HANDLE_INSTRUCTION(CallDirectEval);
LibJS: Allocate context up front when calling with argument array This necessitated splitting CallWithArgumentArray into three variants, one for each call type (call, construct and direct eval).
2025-08-30 11:00:54 +02:00
HANDLE_INSTRUCTION(CallDirectEvalWithArgumentArray);
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
HANDLE_INSTRUCTION(CallWithArgumentArray);
LibJS/Bytecode: Skip unnecessary exception checks in interpreter Many opcodes cannot ever throw an exception, so we can just avoid checking it after executing them.
2024-05-09 15:24:34 +02:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(Catch);
Revert "LibJS: Remove unnecessary ConcatString bytecode instruction" This reverts commit 420187ba7c3afbd9792a3042a65978666c2de7f7. Caused 41 regressions in test262.
2025-12-10 09:17:05 -06:00
HANDLE_INSTRUCTION(ConcatString);
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
HANDLE_INSTRUCTION(CopyObjectExcludingProperties);
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(CreateAsyncFromSyncIterator);
HANDLE_INSTRUCTION(CreateDataPropertyOrThrow);
LibJS: Generate bytecode for the BlockDeclarationInstantiation AO This necessitated adding some new instructions for creating mutable and immutable bindings.
2025-10-25 14:06:48 +02:00
HANDLE_INSTRUCTION(CreateImmutableBinding);
HANDLE_INSTRUCTION(CreateMutableBinding);
LibJS/Bytecode: Skip unnecessary exception checks in interpreter Many opcodes cannot ever throw an exception, so we can just avoid checking it after executing them.
2024-05-09 15:24:34 +02:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(CreateLexicalEnvironment);
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(CreateVariableEnvironment);
LibJS: Stop using execute_ast_node() for class property evaluation Instead, generate bytecode to execute their AST nodes and save the resulting operands inside the NewClass instruction. Moving property expression evaluation to happen before NewClass execution also moves along creation of new private environment and its population with private members (private members should be visible during property evaluation). Before: - NewClass After: - CreatePrivateEnvironment - AddPrivateName - ... - AddPrivateName - NewClass - LeavePrivateEnvironment
2024-05-11 22:54:41 +00:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(CreatePrivateEnvironment);
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
HANDLE_INSTRUCTION(CreateVariable);
LibJS: Remove unnecessary exception checks in bytecode dispatch No need to check for exceptions after instructions that cannot throw.
2025-04-04 13:48:59 +02:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(CreateRestParams);
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(CreateArguments);
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
HANDLE_INSTRUCTION(Decrement);
HANDLE_INSTRUCTION(DeleteById);
HANDLE_INSTRUCTION(DeleteByValue);
HANDLE_INSTRUCTION(DeleteVariable);
HANDLE_INSTRUCTION(Div);
HANDLE_INSTRUCTION(EnterObjectEnvironment);
HANDLE_INSTRUCTION(Exp);
HANDLE_INSTRUCTION(GetById);
HANDLE_INSTRUCTION(GetByIdWithThis);
HANDLE_INSTRUCTION(GetByValue);
HANDLE_INSTRUCTION(GetByValueWithThis);
HANDLE_INSTRUCTION(GetCalleeAndThisFromEnvironment);
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(GetCompletionFields);
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
HANDLE_INSTRUCTION(GetGlobal);
LibJS/Bytecode: Skip unnecessary exception checks in interpreter Many opcodes cannot ever throw an exception, so we can just avoid checking it after executing them.
2024-05-09 15:24:34 +02:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(GetImportMeta);
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(GetLexicalEnvironment);
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
HANDLE_INSTRUCTION(GetIterator);
LibJS/Bytecode: Add dedicated instruction for getting `length` property By doing this, we can remove all the special-case checks for `length` from the generic GetById and GetByIdWithThis code paths, making every other property lookup a bit faster. Small progressions on most benchmarks, and some larger progressions: - 12% on Octane/crypto.js - 6% on Kraken/ai-astar.js
2024-05-20 11:53:28 +02:00
HANDLE_INSTRUCTION(GetLength);
HANDLE_INSTRUCTION(GetLengthWithThis);
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
HANDLE_INSTRUCTION(GetMethod);
LibJS/Bytecode: Skip unnecessary exception checks in interpreter Many opcodes cannot ever throw an exception, so we can just avoid checking it after executing them.
2024-05-09 15:24:34 +02:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(GetNewTarget);
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
HANDLE_INSTRUCTION(GetObjectPropertyIterator);
HANDLE_INSTRUCTION(GetPrivateById);
LibJS: Follow the spec more closely for tagged template literals This resolves a FIXME in its code generation, particularly for: - Caching the template object - Setting the correct property attributes - Freezing the resulting objects This allows archive.org to load, which uses the Lit library. The Lit library caches these template objects to determine if a template has changed, allowing it to determine to do a full template rerender or only partially update the rendering. Before, we would always cause a full rerender on update because we didn't return the same template object. This caused issues with archive.org's code, I believe particularly with its router library, where we would constantly detach and reattach nodes unexpectedly, ending up with the page content not being attached to the router's custom element.
2026-01-06 19:49:38 +00:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(GetTemplateObject);
LibJS/Bytecode: Rename GetVariable => GetBinding
2024-05-14 11:32:04 +02:00
HANDLE_INSTRUCTION(GetBinding);
LibJS: Optimize reading known-to-be-initialized `var` bindings `var` bindings are never in the temporal dead zone (TDZ), and so we know accessing them will not throw. We now take advantage of this by having a specialized environment binding value getter that doesn't check for exceptional cases. 1.08x speedup on JetStream.
2025-05-04 01:41:49 +02:00
HANDLE_INSTRUCTION(GetInitializedBinding);
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
HANDLE_INSTRUCTION(GreaterThan);
HANDLE_INSTRUCTION(GreaterThanEquals);
HANDLE_INSTRUCTION(HasPrivateId);
HANDLE_INSTRUCTION(ImportCall);
HANDLE_INSTRUCTION(In);
HANDLE_INSTRUCTION(Increment);
LibJS/Bytecode: Split SetVariable into four separate instructions Instead of SetVariable having 2x2 modes for variable/lexical and initialize/set, those 4 modes are now separate instructions, which makes each instruction much less branchy.
2024-05-14 11:30:30 +02:00
HANDLE_INSTRUCTION(InitializeLexicalBinding);
HANDLE_INSTRUCTION(InitializeVariableBinding);
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
HANDLE_INSTRUCTION(InstanceOf);
LibJS: Move IsCallable and IsConstructor out of the interpreter loop There's no reason for these to live in the main interpreter loop.
2025-12-04 19:55:07 +01:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(IsCallable);
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(IsConstructor);
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
HANDLE_INSTRUCTION(IteratorClose);
HANDLE_INSTRUCTION(IteratorNext);
LibJS: Optimize array destructuring assignment for builtin iterators ...by avoiding `{ value, done }` iterator result value allocation. This change applies the same otimization 81b6a11 added for `for..in` and `for..of`. Makes following micro benchmark go 22% faster on my computer: ```js function f() { const arr = []; for (let i = 0; i < 10_000_000; i++) { arr.push([i]); } let sum = 0; for (let [i] of arr) { sum += i; } } f(); ```
2025-05-01 16:05:24 +03:00
HANDLE_INSTRUCTION(IteratorNextUnpack);
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
HANDLE_INSTRUCTION(IteratorToArray);
LibJS: Stop using execute_ast_node() for class property evaluation Instead, generate bytecode to execute their AST nodes and save the resulting operands inside the NewClass instruction. Moving property expression evaluation to happen before NewClass execution also moves along creation of new private environment and its population with private members (private members should be visible during property evaluation). Before: - NewClass After: - CreatePrivateEnvironment - AddPrivateName - ... - AddPrivateName - NewClass - LeavePrivateEnvironment
2024-05-11 22:54:41 +00:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(LeavePrivateEnvironment);
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
HANDLE_INSTRUCTION(LeftShift);
HANDLE_INSTRUCTION(LessThan);
HANDLE_INSTRUCTION(LessThanEquals);
HANDLE_INSTRUCTION(LooselyEquals);
HANDLE_INSTRUCTION(LooselyInequals);
HANDLE_INSTRUCTION(Mod);
HANDLE_INSTRUCTION(Mul);
LibJS/Bytecode: Skip unnecessary exception checks in interpreter Many opcodes cannot ever throw an exception, so we can just avoid checking it after executing them.
2024-05-09 15:24:34 +02:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(NewArray);
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
HANDLE_INSTRUCTION(NewArrayWithLength);
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
HANDLE_INSTRUCTION(NewClass);
LibJS/Bytecode: Skip unnecessary exception checks in interpreter Many opcodes cannot ever throw an exception, so we can just avoid checking it after executing them.
2024-05-09 15:24:34 +02:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(NewFunction);
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(NewObject);
LibJS: Add shape caching for object literal instantiation When a function creates object literals with simple property names, we now cache the resulting shape after the first instantiation. On subsequent calls, we create the object with the cached shape directly and write property values at their known offsets. This avoids repeated shape transitions and property offset lookups for a common JavaScript pattern. The optimization uses two new bytecode instructions: - CacheObjectShape: Captures the final shape after object construction - InitObjectLiteralProperty: Writes properties using cached offsets Only "simple" object literals are optimized (string literal keys with simple value expressions). Complex cases like computed properties, getters/setters, and spread elements use the existing slow path. 3.4x speedup on a microbenchmark that repeatedly instantiates an object literal with 26 properties. Small progressions on various benchmarks.
2026-01-09 18:55:00 +01:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(CacheObjectShape);
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(InitObjectLiteralProperty);
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(NewObjectWithNoPrototype);
LibJS/Bytecode: Skip unnecessary exception checks in interpreter Many opcodes cannot ever throw an exception, so we can just avoid checking it after executing them.
2024-05-09 15:24:34 +02:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(NewPrimitiveArray);
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(NewRegExp);
LibJS: Throw ReferenceError for delete super[...] at codegen time delete super.x and delete super[expr] always throw a ReferenceError per spec. Instead of deferring this to runtime via DeleteByIdWithThis and DeleteByValueWithThis instructions, emit the throw directly during bytecode generation. Remove the now-unused DeleteByIdWithThis and DeleteByValueWithThis instructions, and add a NewReferenceError instruction.
2026-02-11 13:14:52 +01:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(NewReferenceError);
LibJS/Bytecode: Skip unnecessary exception checks in interpreter Many opcodes cannot ever throw an exception, so we can just avoid checking it after executing them.
2024-05-09 15:24:34 +02:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(NewTypeError);
LibJS: Mark Not and Typeof as non-throwing instructions
2025-12-04 21:53:10 +01:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(Not);
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
HANDLE_INSTRUCTION(PostfixDecrement);
HANDLE_INSTRUCTION(PostfixIncrement);
LibJS: Split PutBy* instructions into specialized per-kind variants This allows the compiler to fold away lots of unused code for each kind. 1.10x speed-up on MicroBench/pic-add-own.js :^)
2025-10-10 12:09:34 +02:00
LibJS: Consolidate Put bytecode instructions and reduce code bloat Replace 20 separate Put instructions (5 PutKinds x 4 forms) with 4 unified instructions (PutById, PutByIdWithThis, PutByValue, PutByValueWithThis), each carrying a PutKind field at runtime instead of being a separate opcode. This reduces the number of handler entry points in the dispatch loop and eliminates template instantiations of put_by_property_key and put_by_value that were being duplicated 5x each when inlined by LTO.
2026-03-04 10:33:38 +01:00
HANDLE_INSTRUCTION(PutById);
HANDLE_INSTRUCTION(PutByIdWithThis);
HANDLE_INSTRUCTION(PutByValue);
HANDLE_INSTRUCTION(PutByValueWithThis);
LibJS: Split PutBy* instructions into specialized per-kind variants This allows the compiler to fold away lots of unused code for each kind. 1.10x speed-up on MicroBench/pic-add-own.js :^)
2025-10-10 12:09:34 +02:00
LibJS: Add `PutBySpread` instruction This object property kind had completely different behaviour. By adding an instruction for it, we can remove a bunch of special casing, and avoid creating dummy `PropertyKey` values.
2024-11-01 22:00:32 +01:00
HANDLE_INSTRUCTION(PutBySpread);
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
HANDLE_INSTRUCTION(PutPrivateById);
HANDLE_INSTRUCTION(ResolveSuperBase);
HANDLE_INSTRUCTION(ResolveThisBinding);
HANDLE_INSTRUCTION(RightShift);
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(SetCompletionType);
LibJS: Add SetGlobal bytecode instruction for cached global writes Before this change, setting a global would end up as SetLexicalBinding. That instruction always failed to cache the access if the global was a property of the global object. 1.14x speedup on Octane/earley-boyer.js 2.04x speedup on MicroBench/for-of.js Note that MicroBench/for-of.js was more of a "set global" benchmark before this. After this change, it's actually a for..of benchmark. :^)
2025-05-01 23:58:38 +02:00
HANDLE_INSTRUCTION(SetGlobal);
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(SetLexicalEnvironment);
LibJS/Bytecode: Split SetVariable into four separate instructions Instead of SetVariable having 2x2 modes for variable/lexical and initialize/set, those 4 modes are now separate instructions, which makes each instruction much less branchy.
2024-05-14 11:30:30 +02:00
HANDLE_INSTRUCTION(SetLexicalBinding);
HANDLE_INSTRUCTION(SetVariableBinding);
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
HANDLE_INSTRUCTION(StrictlyEquals);
HANDLE_INSTRUCTION(StrictlyInequals);
HANDLE_INSTRUCTION(Sub);
HANDLE_INSTRUCTION(SuperCallWithArgumentArray);
HANDLE_INSTRUCTION(ThrowIfNotObject);
HANDLE_INSTRUCTION(ThrowIfNullish);
HANDLE_INSTRUCTION(ThrowIfTDZ);
LibJS: Do not allow reassignment to local const variable
2026-02-09 20:27:31 +01:00
HANDLE_INSTRUCTION(ThrowConstAssignment);
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
HANDLE_INSTRUCTION(ToLength);
HANDLE_INSTRUCTION(ToObject);
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(ToBoolean);
LibJS: Mark Not and Typeof as non-throwing instructions
2025-12-04 21:53:10 +01:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(Typeof);
LibJS/Bytecode: Rename TypeofVariable => TypeofBinding
2024-06-14 09:37:26 +02:00
HANDLE_INSTRUCTION(TypeofBinding);
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
HANDLE_INSTRUCTION(UnaryMinus);
HANDLE_INSTRUCTION(UnaryPlus);
HANDLE_INSTRUCTION(UnsignedRightShift);
LibJS: Don't check for exceptions after Throw instruction There's always an exception, so just *assume* there is one!
2025-12-04 23:13:55 +01:00
handle_Throw: {
auto& instruction = *reinterpret_cast<Op::Throw const*>(&bytecode[program_counter]);
auto result = instruction.execute_impl(*this);
if (handle_exception(program_counter, result.error_value()) == HandleExceptionResponse::ExitFromExecutable)
return;
LibJS: Inline JS-to-JS calls in the bytecode interpreter dispatch loop Instead of recursing through 5 native stack frames per JS function call (execute_call -> internal_call -> ordinary_call_evaluate_body -> run_executable -> run_bytecode), handle Call and CallConstruct for normal ECMAScript functions directly in the dispatch loop. The fast path allocates the callee's execution context on the InterpreterStack, copies arguments, sets up the environment, and jumps to the callee's bytecode entry point. Return and End unwind inline frames by restoring the caller's state. Exception unwinding walks through inline frames to find handlers. The fast path code is kept in NEVER_INLINE helper functions (try_inline_call, try_inline_call_construct, pop_inline_frame) to minimize register pressure in the dispatch loop. handle_exception takes program_counter by value to avoid forcing it onto the stack. Reloading of bytecode/program_counter after frame switches is done inline at each call site via RELOAD_AND_GOTO_START to preserve a single dispatch entry point for optimal indirect branch prediction.
2026-03-04 10:33:29 +01:00
RELOAD_AND_GOTO_START();
LibJS: Don't check for exceptions after Throw instruction There's always an exception, so just *assume* there is one!
2025-12-04 23:13:55 +01:00
}
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
handle_Await: {
auto& instruction = *reinterpret_cast<Op::Await const*>(&bytecode[program_counter]);
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
instruction.execute_impl(*this);
LibJS: Make return control flow more static With this only `ContinuePendingUnwind` needs to dynamically check if a scheduled return needs to go through a `finally` block, making the interpreter loop a bit nicer
2024-05-12 11:03:26 +02:00
return;
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
}
LibJS/Bytecode: Unroll the bytecode interpreter This commit adds a HANDLE_INSTRUCTION macro that expands to everything needed to handle a single instruction (invoking the handler function, checking for exceptions, and advancing the program counter). This gives a ~15% speed-up on a for loop microbenchmark, and makes basically everything faster.
2024-05-06 10:42:52 +02:00
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
handle_Return: {
auto& instruction = *reinterpret_cast<Op::Return const*>(&bytecode[program_counter]);
LibJS: Inline JS-to-JS calls in the bytecode interpreter dispatch loop Instead of recursing through 5 native stack frames per JS function call (execute_call -> internal_call -> ordinary_call_evaluate_body -> run_executable -> run_bytecode), handle Call and CallConstruct for normal ECMAScript functions directly in the dispatch loop. The fast path allocates the callee's execution context on the InterpreterStack, copies arguments, sets up the environment, and jumps to the callee's bytecode entry point. Return and End unwind inline frames by restoring the caller's state. Exception unwinding walks through inline frames to find handlers. The fast path code is kept in NEVER_INLINE helper functions (try_inline_call, try_inline_call_construct, pop_inline_frame) to minimize register pressure in the dispatch loop. handle_exception takes program_counter by value to avoid forcing it onto the stack. Reloading of bytecode/program_counter after frame switches is done inline at each call site via RELOAD_AND_GOTO_START to preserve a single dispatch entry point for optimal indirect branch prediction.
2026-03-04 10:33:29 +01:00
auto return_value = get(instruction.value());
if (return_value.is_special_empty_value())
return_value = js_undefined();
if (m_running_execution_context->caller_frame) {
pop_inline_frame(return_value);
RELOAD_AND_GOTO_START();
}
reg(Register::return_value()) = return_value;
reg(Register::exception()) = js_special_empty_value();
LibJS: Make return control flow more static With this only `ContinuePendingUnwind` needs to dynamically check if a scheduled return needs to go through a `finally` block, making the interpreter loop a bit nicer
2024-05-12 11:03:26 +02:00
return;
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
}
LibJS: Inline flow control ops in the bytecode interpreter loop Instead of calling out to helper functions for flow control (and then checking control flags on every iteration), we now simply inline those ops in the interpreter loop directly.
2023-09-26 19:43:44 +02:00
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
handle_Yield: {
auto& instruction = *reinterpret_cast<Op::Yield const*>(&bytecode[program_counter]);
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
instruction.execute_impl(*this);
LibJS: Make return control flow more static With this only `ContinuePendingUnwind` needs to dynamically check if a scheduled return needs to go through a `finally` block, making the interpreter loop a bit nicer
2024-05-12 11:03:26 +02:00
return;
LibJS/Bytecode: Thread the bytecode interpreter This commit converts the main loop in Bytecode::Interpreter to use a label table and computed goto for fast instruction dispatch. This yields roughly 35% speedup on the for loop microbenchmark, and makes everything else faster as well. :^)
2024-05-06 16:44:45 +02:00
}
LibJS/Bytecode: Flatten bytecode to a contiguous representation Instead of keeping bytecode as a set of disjoint basic blocks on the malloc heap, bytecode is now a contiguous sequence of bytes(!) The transformation happens at the end of Bytecode::Generator::generate() and the only really hairy part is rerouting jump labels. This required solving a few problems: - The interpreter execution loop had to change quite a bit, since we were storing BasicBlock pointers all over the place, and control transfer was done by redirecting the interpreter's current block. - Exception handlers & finalizers are now stored per-bytecode-range in a side table in Executable. - The interpreter now has a plain program counter instead of a stream iterator. This actually makes error stack generation a bit nicer since we just have to deal with a number instead of reaching into the iterator. This yields a 25% performance improvement on this microbenchmark: for (let i = 0; i < 1_000_000; ++i) { } But basically everything gets faster. :^)
2024-05-06 06:44:08 +02:00
}
LibJS: Add basic support for while loops in the bytecode engine This introduces two new instructions: Jump and JumpIfFalse. Jumps are made to a Bytecode::Label, which is a simple object that represents a location in the bytecode stream. Note that you may not always know the target of a jump when adding the jump instruction itself, but we can just update the instruction later on during codegen once we know where the jump target is. The Bytecode::Interpreter now implements jumping via a jump slot that gets checked after each instruction to see if a jump is pending. If not, we just increment the PC as usual.
2021-06-04 12:07:38 +02:00
}
LibJS: Move bytecode interpreter's inner loop to its own function
2023-09-26 16:41:42 +02:00
}
LibJS: Give Interpreter a direct pointer to the identifier table This gets rid of a lot of pointer chasing from interpreter to executable to identifier table to the actual identifier. 1.05x speed-up on Kraken/ai-astar.js
2025-10-07 16:47:41 +02:00
Utf16FlyString const& Interpreter::get_identifier(IdentifierTableIndex index) const
{
LibJS: Remove derivable fields from ExecutionContext Remove four fields that are trivially derivable from other fields already present in the ExecutionContext: - global_object (from realm) - global_declarative_environment (from realm) - identifier_table (from executable) - property_key_table (from executable) This shrinks ExecutionContext from 192 to 160 bytes (-17%). The asmint's GetGlobal/SetGlobal handlers now load through the realm pointer, taking advantage of the cached declarative environment pointer added in the previous commit.
2026-03-08 11:34:32 +01:00
return m_running_execution_context->executable->get_identifier(index);
LibJS: Give Interpreter a direct pointer to the identifier table This gets rid of a lot of pointer chasing from interpreter to executable to identifier table to the actual identifier. 1.05x speed-up on Kraken/ai-astar.js
2025-10-07 16:47:41 +02:00
}
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
PropertyKey const& Interpreter::get_property_key(PropertyKeyTableIndex index) const
{
LibJS: Remove derivable fields from ExecutionContext Remove four fields that are trivially derivable from other fields already present in the ExecutionContext: - global_object (from realm) - global_declarative_environment (from realm) - identifier_table (from executable) - property_key_table (from executable) This shrinks ExecutionContext from 192 to 160 bytes (-17%). The asmint's GetGlobal/SetGlobal handlers now load through the realm pointer, taking advantage of the cached declarative environment pointer added in the previous commit.
2026-03-08 11:34:32 +01:00
return m_running_execution_context->executable->get_property_key(index);
}
DeclarativeEnvironment& Interpreter::global_declarative_environment()
{
return realm().global_declarative_environment();
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
}
LibJS: Only assign initial "accumulator" value if actually provided
2025-10-31 21:18:56 +01:00
ThrowCompletionOr<Value> Interpreter::run_executable(ExecutionContext& context, Executable& executable, Optional<size_t> entry_point)
LibJS: Move bytecode interpreter's inner loop to its own function
2023-09-26 16:41:42 +02:00
{
LibJS: Pass ExecutionContext to Interpreter::run_executable() This avoids having to get it from the VM's context stack, since most callers already have it on hand.
2025-10-29 09:32:38 +01:00
dbgln_if(JS_BYTECODE_DEBUG, "Bytecode::Interpreter will run unit {}", &executable);
LibJS: Move bytecode interpreter's inner loop to its own function
2023-09-26 16:41:42 +02:00
LibJS: Pass ExecutionContext to Interpreter::run_executable() This avoids having to get it from the VM's context stack, since most callers already have it on hand.
2025-10-29 09:32:38 +01:00
// NOTE: This is how we "push" a new execution context onto the interpreter stack.
TemporaryChange restore_running_execution_context { m_running_execution_context, &context };
LibJS: Move all per-frame state from Interpreter to ExecutionContext This simplifies function entry/exit and lets us just walk away from the used ExecutionContext instead of resetting a bunch of its state when returning control to the caller.
2025-10-29 09:16:25 +01:00
LibJS: Pass ExecutionContext to Interpreter::run_executable() This avoids having to get it from the VM's context stack, since most callers already have it on hand.
2025-10-29 09:32:38 +01:00
context.executable = executable;
LibJS: Move all per-frame state from Interpreter to ExecutionContext This simplifies function entry/exit and lets us just walk away from the used ExecutionContext instead of resetting a bunch of its state when returning control to the caller.
2025-10-29 09:16:25 +01:00
LibJS: Skip initializing constant slots in ExecutionContext Every function call allocates an ExecutionContext with a trailing array of Values for registers, locals, constants, and arguments. Previously, the constructor would initialize all slots to js_special_empty_value(), but constant slots were then immediately overwritten by the interpreter copying in values from the Executable before execution began. To eliminate this redundant initialization, we rearrange the layout from [registers | constants | locals] to [registers | locals | constants]. This groups registers and locals together at the front, allowing us to initialize only those slots while leaving constant slots uninitialized until they're populated with their actual values. This reduces the per-call initialization cost from O(registers + locals + constants) to O(registers + locals). Also tightens up the types involved (size_t -> u32) and adds VERIFYs to guard against overflow when computing the combined slot counts, and to ensure the total fits within the 29-bit operand index field.
2026-01-18 23:17:10 +01:00
VERIFY(executable.registers_and_locals_count + executable.constants.size() == executable.registers_and_locals_and_constants_count);
VERIFY(executable.registers_and_locals_and_constants_count <= context.registers_and_constants_and_locals_and_arguments_span().size());
LibJS: Move bytecode interpreter's inner loop to its own function
2023-09-26 16:41:42 +02:00
LibJS: Don't overwrite cached `this` value on async/generator reentry When resuming execution of a suspended function, we must not overwrite any cached `this` value with something from the ExecutionContext. This was causing an empty JS::Value to leak into the VM when resuming an async arrow function, since the "this mode" for such functions is lexical and thus ExecutionContext will have an empty `this`. It became a problem due to the bytecode optimization where we allow ourselves to assume that `this` remains cached after we've executed a ResolveThisBinding in this (or the first) basic block of the executable. Fixes https://github.com/LadybirdBrowser/ladybird/issues/138
2024-06-20 09:51:06 +02:00
// NOTE: We only copy the `this` value from ExecutionContext if it's not already set.
// If we are re-entering an async/generator context, the `this` value
// may have already been cached by a ResolveThisBinding instruction,
// and subsequent instructions expect this value to be set.
LibJS: Make Value() default-construct the undefined value The special empty value (that we use for array holes, Optional<Value> when empty and a few other other placeholder/sentinel tasks) still exists, but you now create one via JS::js_special_empty_value() and check for it with Value::is_special_empty_value(). The main idea here is to make it very unlikely to accidentally create an unexpected special empty value.
2025-04-04 23:16:34 +02:00
if (reg(Register::this_value()).is_special_empty_value())
LibJS: Pass ExecutionContext to Interpreter::run_executable() This avoids having to get it from the VM's context stack, since most callers already have it on hand.
2025-10-29 09:32:38 +01:00
reg(Register::this_value()) = context.this_value.value_or(js_special_empty_value());
LibJS: Merge CallFrame into ExecutionContext Before this change both ExecutionContext and CallFrame were created before executing function/module/script with a couple exceptions: - executable created for default function argument evaluation has to run in function's execution context. - `execute_ast_node()` where executable compiled for ASTNode has to be executed in running execution context. This change moves all members previously owned by CallFrame into ExecutionContext, and makes two exceptions where an executable that does not have a corresponding execution context saves and restores registers before running. Now, all execution state lives in a single entity, which makes it a bit easier to reason about and opens opportunities for optimizations, such as moving registers and local variables into a single array.
2024-05-01 19:33:49 +02:00
LibJS: Skip initializing constant slots in ExecutionContext Every function call allocates an ExecutionContext with a trailing array of Values for registers, locals, constants, and arguments. Previously, the constructor would initialize all slots to js_special_empty_value(), but constant slots were then immediately overwritten by the interpreter copying in values from the Executable before execution began. To eliminate this redundant initialization, we rearrange the layout from [registers | constants | locals] to [registers | locals | constants]. This groups registers and locals together at the front, allowing us to initialize only those slots while leaving constant slots uninitialized until they're populated with their actual values. This reduces the per-call initialization cost from O(registers + locals + constants) to O(registers + locals). Also tightens up the types involved (size_t -> u32) and adds VERIFYs to guard against overflow when computing the combined slot counts, and to ensure the total fits within the 29-bit operand index field.
2026-01-18 23:17:10 +01:00
// NB: Layout is [registers | locals | constants | arguments], so constants start after registers+locals.
auto* values = context.registers_and_constants_and_locals_and_arguments();
LibJS: Inline JS-to-JS calls in the bytecode interpreter dispatch loop Instead of recursing through 5 native stack frames per JS function call (execute_call -> internal_call -> ordinary_call_evaluate_body -> run_executable -> run_bytecode), handle Call and CallConstruct for normal ECMAScript functions directly in the dispatch loop. The fast path allocates the callee's execution context on the InterpreterStack, copies arguments, sets up the environment, and jumps to the callee's bytecode entry point. Return and End unwind inline frames by restoring the caller's state. Exception unwinding walks through inline frames to find handlers. The fast path code is kept in NEVER_INLINE helper functions (try_inline_call, try_inline_call_construct, pop_inline_frame) to minimize register pressure in the dispatch loop. handle_exception takes program_counter by value to avoid forcing it onto the stack. Reloading of bytecode/program_counter after frame switches is done inline at each call site via RELOAD_AND_GOTO_START to preserve a single dispatch entry point for optimal indirect branch prediction.
2026-03-04 10:33:29 +01:00
if (auto count = executable.constants.size())
memcpy(values + executable.registers_and_locals_count,
executable.constants.data(),
count * sizeof(Value));
LibJS: Join locals, constants and registers into single vector Merging registers, constants and locals into single vector means: - Better data locality - No need to check type in Interpreter::get() and Interpreter::set() which are very hot functions Performance improvement is visible in almost all Octane and Kraken tests.
2024-05-12 18:49:03 +02:00
LibJS/Bytecode: Flatten bytecode to a contiguous representation Instead of keeping bytecode as a set of disjoint basic blocks on the malloc heap, bytecode is now a contiguous sequence of bytes(!) The transformation happens at the end of Bytecode::Generator::generate() and the only really hairy part is rerouting jump labels. This required solving a few problems: - The interpreter execution loop had to change quite a bit, since we were storing BasicBlock pointers all over the place, and control transfer was done by redirecting the interpreter's current block. - Exception handlers & finalizers are now stored per-bytecode-range in a side table in Executable. - The interpreter now has a plain program counter instead of a stream iterator. This actually makes error stack generation a bit nicer since we just have to deal with a number instead of reaching into the iterator. This yields a 25% performance improvement on this microbenchmark: for (let i = 0; i < 1_000_000; ++i) { } But basically everything gets faster. :^)
2024-05-06 06:44:08 +02:00
run_bytecode(entry_point.value_or(0));
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
LibJS: Pass ExecutionContext to Interpreter::run_executable() This avoids having to get it from the VM's context stack, since most callers already have it on hand.
2025-10-29 09:32:38 +01:00
dbgln_if(JS_BYTECODE_DEBUG, "Bytecode::Interpreter did run unit {}", context.executable);
LibJS: Move bytecode debug spam behind JS_BYTECODE_DEBUG :^)
2021-06-07 15:17:37 +02:00
if constexpr (JS_BYTECODE_DEBUG) {
LibJS: Join locals, constants and registers into single vector Merging registers, constants and locals into single vector means: - Better data locality - No need to check type in Interpreter::get() and Interpreter::set() which are very hot functions Performance improvement is visible in almost all Octane and Kraken tests.
2024-05-12 18:49:03 +02:00
for (size_t i = 0; i < executable.number_of_registers; ++i) {
LibJS: Convert remaining usages of Value::TDSWOSE to Value::TSWOSE Note the couple of cases using MUST are just debugging statements.
2023-02-12 21:54:02 -05:00
String value_string;
LibJS: Skip initializing constant slots in ExecutionContext Every function call allocates an ExecutionContext with a trailing array of Values for registers, locals, constants, and arguments. Previously, the constructor would initialize all slots to js_special_empty_value(), but constant slots were then immediately overwritten by the interpreter copying in values from the Executable before execution began. To eliminate this redundant initialization, we rearrange the layout from [registers | constants | locals] to [registers | locals | constants]. This groups registers and locals together at the front, allowing us to initialize only those slots while leaving constant slots uninitialized until they're populated with their actual values. This reduces the per-call initialization cost from O(registers + locals + constants) to O(registers + locals). Also tightens up the types involved (size_t -> u32) and adds VERIFYs to guard against overflow when computing the combined slot counts, and to ensure the total fits within the 29-bit operand index field.
2026-01-18 23:17:10 +01:00
if (values[i].is_special_empty_value())
AK: Make "foo"_string infallible Stop worrying about tiny OOMs. Work towards #20405.
2023-08-07 11:12:38 +02:00
value_string = "(empty)"_string;
LibJS: Move bytecode debug spam behind JS_BYTECODE_DEBUG :^)
2021-06-07 15:17:37 +02:00
else
LibJS: Skip initializing constant slots in ExecutionContext Every function call allocates an ExecutionContext with a trailing array of Values for registers, locals, constants, and arguments. Previously, the constructor would initialize all slots to js_special_empty_value(), but constant slots were then immediately overwritten by the interpreter copying in values from the Executable before execution began. To eliminate this redundant initialization, we rearrange the layout from [registers | constants | locals] to [registers | locals | constants]. This groups registers and locals together at the front, allowing us to initialize only those slots while leaving constant slots uninitialized until they're populated with their actual values. This reduces the per-call initialization cost from O(registers + locals + constants) to O(registers + locals). Also tightens up the types involved (size_t -> u32) and adds VERIFYs to guard against overflow when computing the combined slot counts, and to ensure the total fits within the 29-bit operand index field.
2026-01-18 23:17:10 +01:00
value_string = values[i].to_string_without_side_effects();
LibJS: Move bytecode debug spam behind JS_BYTECODE_DEBUG :^)
2021-06-07 15:17:37 +02:00
dbgln("[{:3}] {}", i, value_string);
}
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
}
LibJS: Compile ScriptFunctions into bytecode and run them that way :^) If there's a current Bytecode::Interpreter in action, ScriptFunction will now compile itself into bytecode and execute in that context. This patch also adds the Return bytecode instruction so that we can actually return values from called functions. :^) Return values are propagated from callee to caller via the caller's $0 register. Bytecode::Interpreter now keeps a stack of register "windows". These are not very efficient, but it should be pretty straightforward to convert them to e.g a sliding register window architecture later on. This is pretty dang cool! :^)
2021-06-05 15:53:36 +02:00
LibJS: Run the queued promise reaction jobs on bytecode interpreter exit This is the same as what the AST interpreter does.
2021-11-11 00:44:56 +03:30
vm().run_queued_promise_jobs();
LibJS: Store and maintain an "execution generation" counter This counter is increased each time a synchronous execution sequence completes, and will allow us to emulate the abstract operations AddToKeptObjects & ClearKeptObjects efficiently.
2021-06-12 17:32:54 +03:00
vm().finish_execution_generation();
LibJS: Use return_value register for "last completion" return values This simplifies the epilogue in run_executable().
2025-10-30 22:32:15 +01:00
auto exception = reg(Register::exception());
LibJS: Make run_executable() return simple ThrowCompletionOr<Value> We don't need to return two values; running an executable only ever produces a throw completion, or a normal completion, i.e a Value. This necessitated a few minor changes, such as adding a way to check if a JS::Cell is a GeneratorResult.
2025-10-30 10:27:47 +01:00
if (!exception.is_special_empty_value()) [[unlikely]]
return throw_completion(exception);
LibJS: Use return_value register for "last completion" return values This simplifies the epilogue in run_executable().
2025-10-30 22:32:15 +01:00
LibJS: Coerce empty completion to "undefined" early in Interpreter Instead of always checking if we're about to return an empty completion value in Interpreter::run_executable(), we now coerce empty completions to the undefined value earlier instead. This simplifies the most common path through run_executable(), giving us a small speedup.
2025-10-31 21:10:51 +01:00
return reg(Register::return_value());
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
void Interpreter::catch_exception(Operand dst)
{
set(dst, reg(Register::exception()));
reg(Register::exception()) = js_special_empty_value();
LibJS/JIT: Support the EnterObjectEnvironment bytecode instruction We can now use `with` statements in jitted code. :^)
2023-11-12 00:12:21 +01:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
GC::Ref<Bytecode::Executable> compile(VM& vm, ASTNode const& node, FunctionKind kind, Utf16FlyString const& name)
LibJS/Bytecode: Simplify Bytecode::Interpreter lifetime model The JS::VM now owns the one Bytecode::Interpreter. We no longer have multiple bytecode interpreters, and there is no concept of a "current" bytecode interpreter. If you ask for VM::bytecode_interpreter_if_exists(), it will return null if we're not running the program in "bytecode enabled" mode. If you ask for VM::bytecode_interpreter(), it will return a bytecode interpreter in all modes. This is used for situations where even the AST interpreter switches to bytecode mode (generators, etc.)
2023-06-22 15:59:18 +02:00
{
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto bytecode_executable = Bytecode::Generator::generate_from_ast_node(vm, node, kind);
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
bytecode_executable->name = name;
if (Bytecode::g_dump_bytecode)
bytecode_executable->dump();
return bytecode_executable;
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
GC::Ref<Bytecode::Executable> compile(VM& vm, GC::Ref<SharedFunctionInstanceData const> shared_function_instance_data, BuiltinAbstractOperationsEnabled builtin_abstract_operations_enabled)
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
{
LibJS/Bytecode: Make compilation use SharedFunctionInstanceData instead All the data we need for compilation is in SharedFunctionInstanceData, so we shouldn't depend on ECMAScriptFunctionObject. Allows NativeJavaScriptBackedFunction to compile bytecode.
2025-11-06 17:26:02 +00:00
auto const& name = shared_function_instance_data->m_name;
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto bytecode_executable = Bytecode::Generator::generate_from_function(vm, shared_function_instance_data, builtin_abstract_operations_enabled);
LibJS/Bytecode: Simplify Bytecode::Interpreter lifetime model The JS::VM now owns the one Bytecode::Interpreter. We no longer have multiple bytecode interpreters, and there is no concept of a "current" bytecode interpreter. If you ask for VM::bytecode_interpreter_if_exists(), it will return null if we're not running the program in "bytecode enabled" mode. If you ask for VM::bytecode_interpreter(), it will return a bytecode interpreter in all modes. This is used for situations where even the AST interpreter switches to bytecode mode (generators, etc.)
2023-06-22 15:59:18 +02:00
bytecode_executable->name = name;
LibJS: Remove the concept of bytecode optimization levels While this would be useful in the future for implementing a multi-tiered optimization strategy, currently a binary on/off is enough for us. This removes the confusingly on-by-default `OptimizationLevel::None` option which made the optimization pipeline a no-op even if `Bytecode::Interpreter::set_optimizations_enabled` had been called. Fixes #15982
2023-06-26 20:10:11 +02:00
LibJS/Bytecode: Simplify Bytecode::Interpreter lifetime model The JS::VM now owns the one Bytecode::Interpreter. We no longer have multiple bytecode interpreters, and there is no concept of a "current" bytecode interpreter. If you ask for VM::bytecode_interpreter_if_exists(), it will return null if we're not running the program in "bytecode enabled" mode. If you ask for VM::bytecode_interpreter(), it will return a bytecode interpreter in all modes. This is used for situations where even the AST interpreter switches to bytecode mode (generators, etc.)
2023-06-22 15:59:18 +02:00
if (Bytecode::g_dump_bytecode)
bytecode_executable->dump();
return bytecode_executable;
}
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
// NOTE: This function assumes that the index is valid within the TypedArray,
// and that the TypedArray is not detached.
template<typename T>
inline Value fast_typed_array_get_element(TypedArrayBase& typed_array, u32 index)
{
Checked<u32> offset_into_array_buffer = index;
offset_into_array_buffer *= sizeof(T);
offset_into_array_buffer += typed_array.byte_offset();
if (offset_into_array_buffer.has_overflow()) [[unlikely]] {
return js_undefined();
}
auto const& array_buffer = *typed_array.viewed_array_buffer();
auto const* slot = reinterpret_cast<T const*>(array_buffer.buffer().offset_pointer(offset_into_array_buffer.value()));
return Value { *slot };
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
}
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
// NOTE: This function assumes that the index is valid within the TypedArray,
// and that the TypedArray is not detached.
template<typename T>
inline void fast_typed_array_set_element(TypedArrayBase& typed_array, u32 index, T value)
{
Checked<u32> offset_into_array_buffer = index;
offset_into_array_buffer *= sizeof(T);
offset_into_array_buffer += typed_array.byte_offset();
if (offset_into_array_buffer.has_overflow()) [[unlikely]] {
return;
}
auto& array_buffer = *typed_array.viewed_array_buffer();
auto* slot = reinterpret_cast<T*>(array_buffer.buffer().offset_pointer(offset_into_array_buffer.value()));
*slot = value;
}
LibJS: Mark all throwing code paths in property access COLD and unlikely
2025-12-10 11:07:00 -06:00
static COLD Completion throw_null_or_undefined_property_get(VM& vm, Value base_value, Optional<IdentifierTableIndex> base_identifier, IdentifierTableIndex property_identifier, Executable const& executable)
LibJS: Make GetById and GetByValue avoid get_identifier() in common case We now defer looking up the various identifiers by IdentifierTableIndex until the last moment. This allows us to avoid the retrieval in common cases like when a property access is cached. Knocks a ~12% item off the profile on https://ventrella.com/Clusters/
2024-07-09 11:37:06 +02:00
{
VERIFY(base_value.is_nullish());
if (base_identifier.has_value())
return vm.throw_completion<TypeError>(ErrorType::ToObjectNullOrUndefinedWithPropertyAndName, executable.get_identifier(property_identifier), base_value, executable.get_identifier(base_identifier.value()));
return vm.throw_completion<TypeError>(ErrorType::ToObjectNullOrUndefinedWithProperty, executable.get_identifier(property_identifier), base_value);
}
LibJS: Mark all throwing code paths in property access COLD and unlikely
2025-12-10 11:07:00 -06:00
static COLD Completion throw_null_or_undefined_property_get(VM& vm, Value base_value, Optional<IdentifierTableIndex> base_identifier, Value property, Executable const& executable)
LibJS: Make GetById and GetByValue avoid get_identifier() in common case We now defer looking up the various identifiers by IdentifierTableIndex until the last moment. This allows us to avoid the retrieval in common cases like when a property access is cached. Knocks a ~12% item off the profile on https://ventrella.com/Clusters/
2024-07-09 11:37:06 +02:00
{
VERIFY(base_value.is_nullish());
if (base_identifier.has_value())
return vm.throw_completion<TypeError>(ErrorType::ToObjectNullOrUndefinedWithPropertyAndName, property, base_value, executable.get_identifier(base_identifier.value()));
return vm.throw_completion<TypeError>(ErrorType::ToObjectNullOrUndefinedWithProperty, property, base_value);
}
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
ALWAYS_INLINE ThrowCompletionOr<GC::Ref<Object>> base_object_for_get(VM& vm, Value base_value, Optional<IdentifierTableIndex> base_identifier, IdentifierTableIndex property_identifier, Executable const& executable)
LibJS: Make GetById and GetByValue avoid get_identifier() in common case We now defer looking up the various identifiers by IdentifierTableIndex until the last moment. This allows us to avoid the retrieval in common cases like when a property access is cached. Knocks a ~12% item off the profile on https://ventrella.com/Clusters/
2024-07-09 11:37:06 +02:00
{
LibJS: Mark more error paths in the interpreter as [[unlikely]]
2025-12-04 10:35:26 +01:00
if (auto base_object = base_object_for_get_impl(vm, base_value)) [[likely]]
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
return GC::Ref { *base_object };
LibJS: Make GetById and GetByValue avoid get_identifier() in common case We now defer looking up the various identifiers by IdentifierTableIndex until the last moment. This allows us to avoid the retrieval in common cases like when a property access is cached. Knocks a ~12% item off the profile on https://ventrella.com/Clusters/
2024-07-09 11:37:06 +02:00
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
// NOTE: At this point this is guaranteed to throw (null or undefined).
LibJS: Make GetById and GetByValue avoid get_identifier() in common case We now defer looking up the various identifiers by IdentifierTableIndex until the last moment. This allows us to avoid the retrieval in common cases like when a property access is cached. Knocks a ~12% item off the profile on https://ventrella.com/Clusters/
2024-07-09 11:37:06 +02:00
return throw_null_or_undefined_property_get(vm, base_value, base_identifier, property_identifier, executable);
}
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
ALWAYS_INLINE ThrowCompletionOr<GC::Ref<Object>> base_object_for_get(VM& vm, Value base_value, Optional<IdentifierTableIndex> base_identifier, Value property, Executable const& executable)
LibJS: Make GetById and GetByValue avoid get_identifier() in common case We now defer looking up the various identifiers by IdentifierTableIndex until the last moment. This allows us to avoid the retrieval in common cases like when a property access is cached. Knocks a ~12% item off the profile on https://ventrella.com/Clusters/
2024-07-09 11:37:06 +02:00
{
LibJS: Mark more error paths in the interpreter as [[unlikely]]
2025-12-04 10:35:26 +01:00
if (auto base_object = base_object_for_get_impl(vm, base_value)) [[likely]]
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
return GC::Ref { *base_object };
LibJS: Make GetById and GetByValue avoid get_identifier() in common case We now defer looking up the various identifiers by IdentifierTableIndex until the last moment. This allows us to avoid the retrieval in common cases like when a property access is cached. Knocks a ~12% item off the profile on https://ventrella.com/Clusters/
2024-07-09 11:37:06 +02:00
// NOTE: At this point this is guaranteed to throw (null or undefined).
return throw_null_or_undefined_property_get(vm, base_value, base_identifier, property, executable);
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
}
LibJS: Make GetById and GetByValue avoid get_identifier() in common case We now defer looking up the various identifiers by IdentifierTableIndex until the last moment. This allows us to avoid the retrieval in common cases like when a property access is cached. Knocks a ~12% item off the profile on https://ventrella.com/Clusters/
2024-07-09 11:37:06 +02:00
inline ThrowCompletionOr<Value> get_by_value(VM& vm, Optional<IdentifierTableIndex> base_identifier, Value base_value, Value property_key_value, Executable const& executable)
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
{
// OPTIMIZATION: Fast path for simple Int32 indexes in array-like objects.
LibJS: Add Value::is_non_negative_int32() This helper combines the check for is_int32() and as_i32() >= 0 in a single mask and compare operation.
2025-12-10 11:46:57 -06:00
if (base_value.is_object() && property_key_value.is_non_negative_int32()) {
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
auto& object = base_value.as_object();
auto index = static_cast<u32>(property_key_value.as_i32());
auto const* object_storage = object.indexed_properties().storage();
// For "non-typed arrays":
if (!object.may_interfere_with_indexed_property_access()
&& object_storage) {
auto maybe_value = [&] {
if (object_storage->is_simple_storage())
return static_cast<SimpleIndexedPropertyStorage const*>(object_storage)->inline_get(index);
else
return static_cast<GenericIndexedPropertyStorage const*>(object_storage)->get(index);
}();
if (maybe_value.has_value()) {
auto value = maybe_value->value;
if (!value.is_accessor())
return value;
}
}
// For typed arrays:
if (object.is_typed_array()) {
auto& typed_array = static_cast<TypedArrayBase&>(object);
auto canonical_index = CanonicalIndex { CanonicalIndex::Type::Index, index };
if (is_valid_integer_index(typed_array, canonical_index)) {
switch (typed_array.kind()) {
case TypedArrayBase::Kind::Uint8Array:
return fast_typed_array_get_element<u8>(typed_array, index);
case TypedArrayBase::Kind::Uint16Array:
return fast_typed_array_get_element<u16>(typed_array, index);
case TypedArrayBase::Kind::Uint32Array:
return fast_typed_array_get_element<u32>(typed_array, index);
case TypedArrayBase::Kind::Int8Array:
return fast_typed_array_get_element<i8>(typed_array, index);
case TypedArrayBase::Kind::Int16Array:
return fast_typed_array_get_element<i16>(typed_array, index);
case TypedArrayBase::Kind::Int32Array:
return fast_typed_array_get_element<i32>(typed_array, index);
case TypedArrayBase::Kind::Uint8ClampedArray:
return fast_typed_array_get_element<u8>(typed_array, index);
LibJS: Add fast paths for get and set on float typed arrays
2024-11-18 01:42:36 +01:00
case TypedArrayBase::Kind::Float16Array:
return fast_typed_array_get_element<f16>(typed_array, index);
case TypedArrayBase::Kind::Float32Array:
return fast_typed_array_get_element<float>(typed_array, index);
case TypedArrayBase::Kind::Float64Array:
return fast_typed_array_get_element<double>(typed_array, index);
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
default:
// FIXME: Support more TypedArray kinds.
break;
}
}
switch (typed_array.kind()) {
#define __JS_ENUMERATE(ClassName, snake_name, PrototypeName, ConstructorName, Type) \
case TypedArrayBase::Kind::ClassName: \
return typed_array_get_element<Type>(typed_array, canonical_index);
JS_ENUMERATE_TYPED_ARRAYS
#undef __JS_ENUMERATE
}
}
}
LibJS: Make GetById and GetByValue avoid get_identifier() in common case We now defer looking up the various identifiers by IdentifierTableIndex until the last moment. This allows us to avoid the retrieval in common cases like when a property access is cached. Knocks a ~12% item off the profile on https://ventrella.com/Clusters/
2024-07-09 11:37:06 +02:00
auto object = TRY(base_object_for_get(vm, base_value, base_identifier, property_key_value, executable));
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
auto property_key = TRY(property_key_value.to_property_key(vm));
if (base_value.is_string()) {
auto string_value = TRY(base_value.as_string().get(vm, property_key));
if (string_value.has_value())
return *string_value;
}
return TRY(object->internal_get(property_key, base_value));
}
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
inline ThrowCompletionOr<Value> get_global(Interpreter& interpreter, IdentifierTableIndex identifier_index, Strict strict, GlobalVariableCache& cache)
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
{
auto& vm = interpreter.vm();
auto& binding_object = interpreter.global_object();
auto& declarative_record = interpreter.global_declarative_environment();
auto& shape = binding_object.shape();
if (cache.environment_serial_number == declarative_record.environment_serial_number()) {
// OPTIMIZATION: For global var bindings, if the shape of the global object hasn't changed,
// we can use the cached property offset.
LibJS: Shrink PropertyLookupCache::Entry size by tweaking layout Reorder members and use u32 instead of Optional<u32> for things that didn't actually need the "empty" state other than for assertions. Reduces memory usage on my x.com home feed by 9.9 MiB.
2025-12-20 16:16:16 -06:00
if (&shape == cache.entries[0].shape && (!shape.is_dictionary() || shape.dictionary_generation() == cache.entries[0].shape_dictionary_generation)) {
auto value = binding_object.get_direct(cache.entries[0].property_offset);
LibJS: Allow GetById to cache getters 1.25x speed-up on this microbenchmark: let o = { get x() { return 1; } }; for (let i = 0; i < 10_000_000; ++i) o.x; I looked into this because I noticed getter invocation when profiling long-running WPT tests. We already had the mechanism for non-getter properties, and the change to support getters turned out to be trivial.
2024-10-17 20:29:07 +02:00
if (value.is_accessor())
LibJS: Pass the global object as receiver in GetGlobal The GetGlobal bytecode optimization bypasses the normal environment record lookup for global variable access. When a global property is an accessor (getter), the receiver passed to the getter must be the global object, not undefined. The spec's Get(O, P) abstract operation is defined as O.[[Get]](P, O), meaning the object itself is always the receiver. The global environment's GetBindingValue delegates to its object record's GetBindingValue, which calls Get(bindingObject, N), so the receiver should be the binding object (the global object). Both the cached path (calling the getter directly from get_direct) and the non-cached path (calling internal_get) were passing js_undefined() as the receiver. This caused strict-mode getters on global properties to receive undefined as their this-value instead of globalThis. Notably, the corresponding SetGlobal paths already correctly passed &binding_object for setter calls.
2026-02-08 11:54:20 +01:00
return TRY(call(vm, value.as_accessor().getter(), &binding_object));
LibJS: Correctly return cached value for global var bindings When the cached value was not an accessor, it was simply ignored. This is the value we really want, so we can just return it. Shows up to 5x improvements on some benchmarks, and 1.4x in general js-benchmarks.
2024-11-12 18:38:35 +01:00
return value;
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
}
// OPTIMIZATION: For global lexical bindings, if the global declarative environment hasn't changed,
// we can use the cached environment binding index.
LibJS: Let GetGlobal cache module environment lookups when possible
2025-03-16 18:39:57 -05:00
if (cache.has_environment_binding_index) {
if (cache.in_module_environment) {
auto module = vm.running_execution_context().script_or_module.get_pointer<GC::Ref<Module>>();
return (*module)->environment()->get_binding_value_direct(vm, cache.environment_binding_index);
}
return declarative_record.get_binding_value_direct(vm, cache.environment_binding_index);
}
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
}
cache.environment_serial_number = declarative_record.environment_serial_number();
LibJS: Give Interpreter a direct pointer to the identifier table This gets rid of a lot of pointer chasing from interpreter to executable to identifier table to the actual identifier. 1.05x speed-up on Kraken/ai-astar.js
2025-10-07 16:47:41 +02:00
auto& identifier = interpreter.get_identifier(identifier_index);
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
LibJS: Store Module::environment() as ModuleEnvironment Let's use a more specific type here to allow for devirtualization.
2025-03-16 17:41:24 -05:00
if (auto* module = vm.running_execution_context().script_or_module.get_pointer<GC::Ref<Module>>()) {
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
// NOTE: GetGlobal is used to access variables stored in the module environment and global environment.
// The module environment is checked first since it precedes the global environment in the environment chain.
LibJS: Store Module::environment() as ModuleEnvironment Let's use a more specific type here to allow for devirtualization.
2025-03-16 17:41:24 -05:00
auto& module_environment = *(*module)->environment();
LibJS: Let GetGlobal cache module environment lookups when possible
2025-03-16 18:39:57 -05:00
Optional<size_t> index;
if (TRY(module_environment.has_binding(identifier, &index))) {
if (index.has_value()) {
cache.environment_binding_index = static_cast<u32>(index.value());
cache.has_environment_binding_index = true;
cache.in_module_environment = true;
return TRY(module_environment.get_binding_value_direct(vm, index.value()));
}
LibJS: Always assume module bindings access is in strict mode Modules are always in strict mode anyway, no need to look at the strictness flag here.
2025-10-29 23:23:36 +01:00
return TRY(module_environment.get_binding_value(vm, identifier, true));
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
}
}
Optional<size_t> offset;
if (TRY(declarative_record.has_binding(identifier, &offset))) {
cache.environment_binding_index = static_cast<u32>(offset.value());
LibJS: Let GetGlobal cache module environment lookups when possible
2025-03-16 18:39:57 -05:00
cache.has_environment_binding_index = true;
cache.in_module_environment = false;
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
return TRY(declarative_record.get_binding_value(vm, identifier, strict == Strict::Yes));
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
}
LibJS: Mark non-throwing path in GetGlobal [[likely]]
2025-12-04 22:38:40 +01:00
if (TRY(binding_object.has_property(identifier))) [[likely]] {
LibJS: Add inline caching for adding new own properties to objects We already had IC support in PutById for the following cases: - Changing an existing own property - Calling a setter located in the prototype chain This was enough to speed up code where structurally identical objects (same shape) are processed in a loop: ```js const arr = [{ a: 1 }, { a: 2 }, { a: 3 }]; for (let obj of arr) { obj.a += 1; } ``` However, creating structurally identical objects in a loop was still slow: ```js for (let i = 0; i < 10_000_000; i++) { const o = {}; o.a = 1; o.b = 2; o.c = 3; } ``` This change addresses that by adding a new IC type that caches both the source and target shapes, allowing property additions to be fast-pathed by directly jumping to the shape that already includes the new property.
2025-09-15 17:23:39 +02:00
CacheableGetPropertyMetadata cacheable_metadata;
LibJS: Pass the global object as receiver in GetGlobal The GetGlobal bytecode optimization bypasses the normal environment record lookup for global variable access. When a global property is an accessor (getter), the receiver passed to the getter must be the global object, not undefined. The spec's Get(O, P) abstract operation is defined as O.[[Get]](P, O), meaning the object itself is always the receiver. The global environment's GetBindingValue delegates to its object record's GetBindingValue, which calls Get(bindingObject, N), so the receiver should be the binding object (the global object). Both the cached path (calling the getter directly from get_direct) and the non-cached path (calling internal_get) were passing js_undefined() as the receiver. This caused strict-mode getters on global properties to receive undefined as their this-value instead of globalThis. Notably, the corresponding SetGlobal paths already correctly passed &binding_object for setter calls.
2026-02-08 11:54:20 +01:00
auto value = TRY(binding_object.internal_get(identifier, &binding_object, &cacheable_metadata));
LibJS: Add inline caching for adding new own properties to objects We already had IC support in PutById for the following cases: - Changing an existing own property - Calling a setter located in the prototype chain This was enough to speed up code where structurally identical objects (same shape) are processed in a loop: ```js const arr = [{ a: 1 }, { a: 2 }, { a: 3 }]; for (let obj of arr) { obj.a += 1; } ``` However, creating structurally identical objects in a loop was still slow: ```js for (let i = 0; i < 10_000_000; i++) { const o = {}; o.a = 1; o.b = 2; o.c = 3; } ``` This change addresses that by adding a new IC type that caches both the source and target shapes, allowing property additions to be fast-pathed by directly jumping to the shape that already includes the new property.
2025-09-15 17:23:39 +02:00
if (cacheable_metadata.type == CacheableGetPropertyMetadata::Type::GetOwnProperty) {
LibJS: Make GetById cache polymorphic Instead of monomorphic (1 shape), GetById inline caches are now polymorphic (4 shapes). This improves inline cache hit rates greatly on most web JavaScript. For example, Speedometer 2.1 sees 88% -> 97% cache hit rate improvement. 1.71x speedup on MicroBench/pic-get-own.js 1.82x speedup on MicroBench/pic-get-pchain.js
2025-05-06 13:16:44 +02:00
cache.entries[0].shape = shape;
cache.entries[0].property_offset = cacheable_metadata.property_offset.value();
LibJS: Track current shape dictionary generation in PropertyLookupCache When an object becomes too big (currently 64 properties or more), we change its shape to a dictionary and don't do any further transitions. However, this means the Shape of the object no longer changes, so the cache invalidation check of `current_shape != cache.shape` is no longer a valid check. This fixes that by keeping track of a generation number for the Shape both on the Shape object and in the cache, allowing that to be checked instead of the Shape identity. The generation is incremented whenever the dictionary is mutated. Fixes stale cache lookups on Gmail preventing emails from being displayed. I was not able to produce a reproduction for this, plus the generation count was over the 20k mark on Gmail.
2025-09-07 15:27:16 +01:00
if (shape.is_dictionary()) {
cache.entries[0].shape_dictionary_generation = shape.dictionary_generation();
}
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
}
return value;
}
return vm.throw_completion<ReferenceError>(ErrorType::UnknownIdentifier, identifier);
}
LibJS: Mark call instruction unhappy paths COLD and [[unlikely]]
2025-12-05 10:49:50 +01:00
static COLD Completion throw_type_error_for_callee(Bytecode::Interpreter& interpreter, Value callee, StringView callee_type, Optional<StringTableIndex> const expression_string)
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
{
auto& vm = interpreter.vm();
if (expression_string.has_value())
LibJS: Pass JS::Value directly to string formatting functions We don't need to call .to_string_without_side_effects() when passing a JS::Value in for string formatting. The Formatter will do it for us.
2025-12-05 08:01:44 +01:00
return vm.throw_completion<TypeError>(ErrorType::IsNotAEvaluatedFrom, callee, callee_type, interpreter.current_executable().get_string(*expression_string));
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
LibJS: Pass JS::Value directly to string formatting functions We don't need to call .to_string_without_side_effects() when passing a JS::Value in for string formatting. The Formatter will do it for us.
2025-12-05 08:01:44 +01:00
return vm.throw_completion<TypeError>(ErrorType::IsNotA, callee, callee_type);
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
}
LibJS: Pass Optional<T> const& by value more in the interpreter code
2025-12-04 10:02:11 +01:00
inline ThrowCompletionOr<void> throw_if_needed_for_call(Interpreter& interpreter, Value callee, Op::CallType call_type, Optional<StringTableIndex> const expression_string)
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
{
if ((call_type == Op::CallType::Call || call_type == Op::CallType::DirectEval)
LibJS: Mark call instruction unhappy paths COLD and [[unlikely]]
2025-12-05 10:49:50 +01:00
&& !callee.is_function()) [[unlikely]]
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
return throw_type_error_for_callee(interpreter, callee, "function"sv, expression_string);
LibJS: Mark call instruction unhappy paths COLD and [[unlikely]]
2025-12-05 10:49:50 +01:00
if (call_type == Op::CallType::Construct && !callee.is_constructor()) [[unlikely]]
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
return throw_type_error_for_callee(interpreter, callee, "constructor"sv, expression_string);
return {};
}
LibJS: Pre-create SharedFunctionInstanceData in NewFunction Replace the FunctionNode const& stored on the NewFunction bytecode instruction with an index into a table of pre-created SharedFunctionInstanceData objects on the Executable. During bytecode compilation, we now eagerly create SharedFunctionInstanceData for each function that will be instantiated by NewFunction, and store it on both the FunctionNode (for caching) and the Executable (for GC tracing). At runtime, NewFunction simply looks up the SharedFunctionInstanceData by index and calls create_from_function_data() directly, bypassing the AST entirely. This removes one of the main reasons the AST had to stay alive after compilation. The instantiate_ordinary_function_expression() helper in Interpreter.cpp is removed as its non-trivial code path (creating a scope for named function expressions) was dead code -- it was only called when !has_name(), so the has_own_name branch never executed.
2026-02-10 23:02:46 +01:00
inline Value new_function(Interpreter& interpreter, u32 shared_function_data_index, Optional<Operand> const home_object)
LibJS: Move InstantiateOrdinaryFunctionExpression into interpreter This is execution time stuff and doesn't belong in the AST.
2025-10-27 13:02:37 +01:00
{
auto& vm = interpreter.vm();
LibJS: Pre-create SharedFunctionInstanceData in NewFunction Replace the FunctionNode const& stored on the NewFunction bytecode instruction with an index into a table of pre-created SharedFunctionInstanceData objects on the Executable. During bytecode compilation, we now eagerly create SharedFunctionInstanceData for each function that will be instantiated by NewFunction, and store it on both the FunctionNode (for caching) and the Executable (for GC tracing). At runtime, NewFunction simply looks up the SharedFunctionInstanceData by index and calls create_from_function_data() directly, bypassing the AST entirely. This removes one of the main reasons the AST had to stay alive after compilation. The instantiate_ordinary_function_expression() helper in Interpreter.cpp is removed as its non-trivial code path (creating a scope for named function expressions) was dead code -- it was only called when !has_name(), so the has_own_name branch never executed.
2026-02-10 23:02:46 +01:00
auto& shared_data = *interpreter.current_executable().shared_function_data[shared_function_data_index];
auto& realm = *vm.current_realm();
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
LibJS: Pre-create SharedFunctionInstanceData in NewFunction Replace the FunctionNode const& stored on the NewFunction bytecode instruction with an index into a table of pre-created SharedFunctionInstanceData objects on the Executable. During bytecode compilation, we now eagerly create SharedFunctionInstanceData for each function that will be instantiated by NewFunction, and store it on both the FunctionNode (for caching) and the Executable (for GC tracing). At runtime, NewFunction simply looks up the SharedFunctionInstanceData by index and calls create_from_function_data() directly, bypassing the AST entirely. This removes one of the main reasons the AST had to stay alive after compilation. The instantiate_ordinary_function_expression() helper in Interpreter.cpp is removed as its non-trivial code path (creating a scope for named function expressions) was dead code -- it was only called when !has_name(), so the has_own_name branch never executed.
2026-02-10 23:02:46 +01:00
GC::Ref<Object> prototype = [&]() -> GC::Ref<Object> {
switch (shared_data.m_kind) {
case FunctionKind::Normal:
return realm.intrinsics().function_prototype();
case FunctionKind::Generator:
return realm.intrinsics().generator_function_prototype();
case FunctionKind::Async:
return realm.intrinsics().async_function_prototype();
case FunctionKind::AsyncGenerator:
return realm.intrinsics().async_generator_function_prototype();
}
VERIFY_NOT_REACHED();
}();
auto function = ECMAScriptFunctionObject::create_from_function_data(
realm, shared_data,
vm.lexical_environment(),
vm.running_execution_context().private_environment,
*prototype);
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
if (home_object.has_value()) {
LibJS: Move InstantiateOrdinaryFunctionExpression into interpreter This is execution time stuff and doesn't belong in the AST.
2025-10-27 13:02:37 +01:00
auto home_object_value = interpreter.get(home_object.value());
LibJS: Pre-create SharedFunctionInstanceData in NewFunction Replace the FunctionNode const& stored on the NewFunction bytecode instruction with an index into a table of pre-created SharedFunctionInstanceData objects on the Executable. During bytecode compilation, we now eagerly create SharedFunctionInstanceData for each function that will be instantiated by NewFunction, and store it on both the FunctionNode (for caching) and the Executable (for GC tracing). At runtime, NewFunction simply looks up the SharedFunctionInstanceData by index and calls create_from_function_data() directly, bypassing the AST entirely. This removes one of the main reasons the AST had to stay alive after compilation. The instantiate_ordinary_function_expression() helper in Interpreter.cpp is removed as its non-trivial code path (creating a scope for named function expressions) was dead code -- it was only called when !has_name(), so the has_own_name branch never executed.
2026-02-10 23:02:46 +01:00
function->set_home_object(&home_object_value.as_object());
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
}
LibJS: Pre-create SharedFunctionInstanceData in NewFunction Replace the FunctionNode const& stored on the NewFunction bytecode instruction with an index into a table of pre-created SharedFunctionInstanceData objects on the Executable. During bytecode compilation, we now eagerly create SharedFunctionInstanceData for each function that will be instantiated by NewFunction, and store it on both the FunctionNode (for caching) and the Executable (for GC tracing). At runtime, NewFunction simply looks up the SharedFunctionInstanceData by index and calls create_from_function_data() directly, bypassing the AST entirely. This removes one of the main reasons the AST had to stay alive after compilation. The instantiate_ordinary_function_expression() helper in Interpreter.cpp is removed as its non-trivial code path (creating a scope for named function expressions) was dead code -- it was only called when !has_name(), so the has_own_name branch never executed.
2026-02-10 23:02:46 +01:00
return function;
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
}
LibJS: Consolidate Put bytecode instructions and reduce code bloat Replace 20 separate Put instructions (5 PutKinds x 4 forms) with 4 unified instructions (PutById, PutByIdWithThis, PutByValue, PutByValueWithThis), each carrying a PutKind field at runtime instead of being a separate opcode. This reduces the number of handler entry points in the dispatch loop and eliminates template instantiations of put_by_property_key and put_by_value that were being duplicated 5x each when inlined by LTO.
2026-03-04 10:33:38 +01:00
inline ThrowCompletionOr<void> put_by_value(VM& vm, Value base, Optional<Utf16FlyString const&> const base_identifier, Value property_key_value, Value value, PutKind kind, Strict strict)
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
{
// OPTIMIZATION: Fast path for simple Int32 indexes in array-like objects.
LibJS: Split PutBy* instructions into specialized per-kind variants This allows the compiler to fold away lots of unused code for each kind. 1.10x speed-up on MicroBench/pic-add-own.js :^)
2025-10-10 12:09:34 +02:00
if (kind == PutKind::Normal
LibJS: Add Value::is_non_negative_int32() This helper combines the check for is_int32() and as_i32() >= 0 in a single mask and compare operation.
2025-12-10 11:46:57 -06:00
&& base.is_object() && property_key_value.is_non_negative_int32()) {
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
auto& object = base.as_object();
auto* storage = object.indexed_properties().storage();
auto index = static_cast<u32>(property_key_value.as_i32());
// For "non-typed arrays":
if (storage
&& storage->is_simple_storage()
&& !object.may_interfere_with_indexed_property_access()) {
auto maybe_value = storage->get(index);
if (maybe_value.has_value()) {
auto existing_value = maybe_value->value;
if (!existing_value.is_accessor()) {
storage->put(index, value);
return {};
}
}
}
// For typed arrays:
if (object.is_typed_array()) {
auto& typed_array = static_cast<TypedArrayBase&>(object);
auto canonical_index = CanonicalIndex { CanonicalIndex::Type::Index, index };
LibJS: Add fast paths for get and set on float typed arrays
2024-11-18 01:42:36 +01:00
if (is_valid_integer_index(typed_array, canonical_index)) {
if (value.is_int32()) {
switch (typed_array.kind()) {
case TypedArrayBase::Kind::Uint8Array:
fast_typed_array_set_element<u8>(typed_array, index, static_cast<u8>(value.as_i32()));
return {};
case TypedArrayBase::Kind::Uint16Array:
fast_typed_array_set_element<u16>(typed_array, index, static_cast<u16>(value.as_i32()));
return {};
case TypedArrayBase::Kind::Uint32Array:
fast_typed_array_set_element<u32>(typed_array, index, static_cast<u32>(value.as_i32()));
return {};
case TypedArrayBase::Kind::Int8Array:
fast_typed_array_set_element<i8>(typed_array, index, static_cast<i8>(value.as_i32()));
return {};
case TypedArrayBase::Kind::Int16Array:
fast_typed_array_set_element<i16>(typed_array, index, static_cast<i16>(value.as_i32()));
return {};
case TypedArrayBase::Kind::Int32Array:
fast_typed_array_set_element<i32>(typed_array, index, value.as_i32());
return {};
case TypedArrayBase::Kind::Uint8ClampedArray:
fast_typed_array_set_element<u8>(typed_array, index, clamp(value.as_i32(), 0, 255));
return {};
default:
break;
}
} else if (value.is_double()) {
switch (typed_array.kind()) {
case TypedArrayBase::Kind::Float16Array:
fast_typed_array_set_element<f16>(typed_array, index, static_cast<f16>(value.as_double()));
return {};
case TypedArrayBase::Kind::Float32Array:
fast_typed_array_set_element<float>(typed_array, index, static_cast<float>(value.as_double()));
return {};
case TypedArrayBase::Kind::Float64Array:
fast_typed_array_set_element<double>(typed_array, index, value.as_double());
return {};
LibJS: Add fast path for float to int put This commit adds a fast path for putting values into a TypedArray of an integer type, when the value being put in is a double. This leads to a 6% speedup on JetStream/gcc-loops.js.
2025-05-13 14:12:50 +02:00
case TypedArrayBase::Kind::Int8Array:
fast_typed_array_set_element<i8>(typed_array, index, MUST(value.to_i8(vm)));
return {};
case TypedArrayBase::Kind::Int16Array:
fast_typed_array_set_element<i16>(typed_array, index, MUST(value.to_i16(vm)));
return {};
case TypedArrayBase::Kind::Int32Array:
fast_typed_array_set_element<i32>(typed_array, index, MUST(value.to_i32(vm)));
return {};
case TypedArrayBase::Kind::Uint8Array:
fast_typed_array_set_element<u8>(typed_array, index, MUST(value.to_u8(vm)));
return {};
case TypedArrayBase::Kind::Uint16Array:
fast_typed_array_set_element<u16>(typed_array, index, MUST(value.to_u16(vm)));
return {};
case TypedArrayBase::Kind::Uint32Array:
fast_typed_array_set_element<u32>(typed_array, index, MUST(value.to_u32(vm)));
return {};
LibJS: Add fast paths for get and set on float typed arrays
2024-11-18 01:42:36 +01:00
default:
break;
}
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
}
LibJS: Add fast paths for get and set on float typed arrays
2024-11-18 01:42:36 +01:00
// FIXME: Support more TypedArray kinds.
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
}
if (typed_array.kind() == TypedArrayBase::Kind::Uint32Array && value.is_integral_number()) {
auto integer = value.as_double();
if (AK::is_within_range<u32>(integer) && is_valid_integer_index(typed_array, canonical_index)) {
fast_typed_array_set_element<u32>(typed_array, index, static_cast<u32>(integer));
return {};
}
}
switch (typed_array.kind()) {
#define __JS_ENUMERATE(ClassName, snake_name, PrototypeName, ConstructorName, Type) \
case TypedArrayBase::Kind::ClassName: \
return typed_array_set_element<Type>(typed_array, canonical_index, value);
JS_ENUMERATE_TYPED_ARRAYS
#undef __JS_ENUMERATE
}
return {};
}
}
LibJS: Add `PutBySpread` instruction This object property kind had completely different behaviour. By adding an instruction for it, we can remove a bunch of special casing, and avoid creating dummy `PropertyKey` values.
2024-11-01 22:00:32 +01:00
auto property_key = TRY(property_key_value.to_property_key(vm));
LibJS: Consolidate Put bytecode instructions and reduce code bloat Replace 20 separate Put instructions (5 PutKinds x 4 forms) with 4 unified instructions (PutById, PutByIdWithThis, PutByValue, PutByValueWithThis), each carrying a PutKind field at runtime instead of being a separate opcode. This reduces the number of handler entry points in the dispatch loop and eliminates template instantiations of put_by_property_key and put_by_value that were being duplicated 5x each when inlined by LTO.
2026-03-04 10:33:38 +01:00
TRY(put_by_property_key(vm, base, base, value, base_identifier, property_key, kind, strict));
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
return {};
}
struct CalleeAndThis {
Value callee;
Value this_value;
};
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
inline ThrowCompletionOr<CalleeAndThis> get_callee_and_this_from_environment(Interpreter& interpreter, Utf16FlyString const& name, Strict strict, EnvironmentCoordinate& cache)
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
{
auto& vm = interpreter.vm();
Value callee = js_undefined();
LibJS: Use [[likely]] annotations for cached environment lookups These will generally be cached the vast majority of the time except on first encounter, and sprinkling [[likely]] gives us a nice boost. 1.10x speed-up on this micro-benchmark: (() => { var a = 3; for (let i = 0; i < 100_000_000; ++i) { a; } eval(""); })();
2025-10-07 16:37:22 +02:00
if (cache.is_valid()) [[likely]] {
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
auto const* environment = interpreter.running_execution_context().lexical_environment.ptr();
LibJS: Limit eval() deoptimization to the containing function scope Previously, when direct eval() was called, we would mark the entire environment chain as "permanently screwed by eval", disabling variable access caching all the way up to the global scope. This was overly conservative. According to the ECMAScript specification, a sloppy direct eval() can only inject var declarations into its containing function's variable environment - it cannot inject variables into parent function scopes. This patch makes two changes: 1. Stop propagating the "screwed by eval" flag at function boundaries. When set_permanently_screwed_by_eval() hits a FunctionEnvironment or GlobalEnvironment, it no longer continues to outer environments. 2. Check each environment during cache lookup traversal. If any environment in the path is marked as screwed, we bail to the slow path. This catches the case where we're inside a function with eval and have a cached coordinate pointing to an outer scope. The second change is necessary because eval can create local variables that shadow outer bindings. When looking up a variable from inside a function that called eval, we can't trust cached coordinates that point to outer scopes, since eval may have created a closer binding. This improves performance for code with nested functions where an inner function uses eval but parent functions perform many variable accesses. The parent functions can now use cached environment coordinates. All 29 new tests verify behavior matches V8.
2026-01-26 20:40:05 +01:00
for (size_t i = 0; i < cache.hops; ++i) {
if (environment->is_permanently_screwed_by_eval()) [[unlikely]]
goto slow_path;
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
environment = environment->outer_environment();
LibJS: Limit eval() deoptimization to the containing function scope Previously, when direct eval() was called, we would mark the entire environment chain as "permanently screwed by eval", disabling variable access caching all the way up to the global scope. This was overly conservative. According to the ECMAScript specification, a sloppy direct eval() can only inject var declarations into its containing function's variable environment - it cannot inject variables into parent function scopes. This patch makes two changes: 1. Stop propagating the "screwed by eval" flag at function boundaries. When set_permanently_screwed_by_eval() hits a FunctionEnvironment or GlobalEnvironment, it no longer continues to outer environments. 2. Check each environment during cache lookup traversal. If any environment in the path is marked as screwed, we bail to the slow path. This catches the case where we're inside a function with eval and have a cached coordinate pointing to an outer scope. The second change is necessary because eval can create local variables that shadow outer bindings. When looking up a variable from inside a function that called eval, we can't trust cached coordinates that point to outer scopes, since eval may have created a closer binding. This improves performance for code with nested functions where an inner function uses eval but parent functions perform many variable accesses. The parent functions can now use cached environment coordinates. All 29 new tests verify behavior matches V8.
2026-01-26 20:40:05 +01:00
}
LibJS: Use [[likely]] annotations for cached environment lookups These will generally be cached the vast majority of the time except on first encounter, and sprinkling [[likely]] gives us a nice boost. 1.10x speed-up on this micro-benchmark: (() => { var a = 3; for (let i = 0; i < 100_000_000; ++i) { a; } eval(""); })();
2025-10-07 16:37:22 +02:00
if (!environment->is_permanently_screwed_by_eval()) [[likely]] {
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
callee = TRY(static_cast<DeclarativeEnvironment const&>(*environment).get_binding_value_direct(vm, cache.index));
LibJS: Mark `with` path in GetCalleeAndThisFromEnvironment [[unlikely]] This doesn't affect interpreter size directly, but let's inform the compiler that we're not terribly worried about code using the `with` statement in JS.
2025-12-04 10:28:38 +01:00
auto this_value = js_undefined();
if (auto base_object = environment->with_base_object()) [[unlikely]]
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
this_value = base_object;
return CalleeAndThis {
.callee = callee,
.this_value = this_value,
};
}
LibJS: Limit eval() deoptimization to the containing function scope Previously, when direct eval() was called, we would mark the entire environment chain as "permanently screwed by eval", disabling variable access caching all the way up to the global scope. This was overly conservative. According to the ECMAScript specification, a sloppy direct eval() can only inject var declarations into its containing function's variable environment - it cannot inject variables into parent function scopes. This patch makes two changes: 1. Stop propagating the "screwed by eval" flag at function boundaries. When set_permanently_screwed_by_eval() hits a FunctionEnvironment or GlobalEnvironment, it no longer continues to outer environments. 2. Check each environment during cache lookup traversal. If any environment in the path is marked as screwed, we bail to the slow path. This catches the case where we're inside a function with eval and have a cached coordinate pointing to an outer scope. The second change is necessary because eval can create local variables that shadow outer bindings. When looking up a variable from inside a function that called eval, we can't trust cached coordinates that point to outer scopes, since eval may have created a closer binding. This improves performance for code with nested functions where an inner function uses eval but parent functions perform many variable accesses. The parent functions can now use cached environment coordinates. All 29 new tests verify behavior matches V8.
2026-01-26 20:40:05 +01:00
slow_path:
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
cache = {};
}
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
auto reference = TRY(vm.resolve_binding(name, strict));
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
if (reference.environment_coordinate().has_value())
cache = reference.environment_coordinate().value();
callee = TRY(reference.get_value(vm));
LibJS: Mark `with` path in GetCalleeAndThisFromEnvironment [[unlikely]] This doesn't affect interpreter size directly, but let's inform the compiler that we're not terribly worried about code using the `with` statement in JS.
2025-12-04 10:28:38 +01:00
Value this_value;
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
if (reference.is_property_reference()) {
this_value = reference.get_this_value();
} else {
if (reference.is_environment_reference()) {
LibJS: Mark `with` path in GetCalleeAndThisFromEnvironment [[unlikely]] This doesn't affect interpreter size directly, but let's inform the compiler that we're not terribly worried about code using the `with` statement in JS.
2025-12-04 10:28:38 +01:00
if (auto base_object = reference.base_environment().with_base_object()) [[unlikely]]
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
this_value = base_object;
}
}
return CalleeAndThis {
.callee = callee,
.this_value = this_value,
};
}
// 13.2.7.3 Runtime Semantics: Evaluation, https://tc39.es/ecma262/#sec-regular-expression-literals-runtime-semantics-evaluation
LibJS: Don't rerun regexp optimizer every time a regexp literal is used
2025-12-12 06:17:37 -06:00
inline Value new_regexp(VM& vm, Regex<ECMA262> const& regex, Utf16String pattern, Utf16String flags)
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
{
// 1. Let pattern be CodePointsToString(BodyText of RegularExpressionLiteral).
// 2. Let flags be CodePointsToString(FlagText of RegularExpressionLiteral).
// 3. Return ! RegExpCreate(pattern, flags).
auto& realm = *vm.current_realm();
// NOTE: We bypass RegExpCreate and subsequently RegExpAlloc as an optimization to use the already parsed values.
LibJS: Don't rerun regexp optimizer every time a regexp literal is used
2025-12-12 06:17:37 -06:00
auto regexp_object = RegExpObject::create(realm, regex, move(pattern), move(flags));
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
// RegExpAlloc has these two steps from the 'Legacy RegExp features' proposal.
regexp_object->set_realm(realm);
// We don't need to check 'If SameValue(newTarget, thisRealm.[[Intrinsics]].[[%RegExp%]]) is true'
// here as we know RegExpCreate calls RegExpAlloc with %RegExp% for newTarget.
regexp_object->set_legacy_features_enabled(true);
return regexp_object;
}
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
inline ThrowCompletionOr<void> create_variable(VM& vm, Utf16FlyString const& name, Op::EnvironmentMode mode, bool is_global, bool is_immutable, bool is_strict)
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
{
if (mode == Op::EnvironmentMode::Lexical) {
VERIFY(!is_global);
// Note: This is papering over an issue where "FunctionDeclarationInstantiation" creates these bindings for us.
// Instead of crashing in there, we'll just raise an exception here.
LibJS: Mark weird error path in CreateVariable as [[unlikely]]
2025-12-04 10:31:54 +01:00
if (TRY(vm.lexical_environment()->has_binding(name))) [[unlikely]]
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
return vm.throw_completion<InternalError>(TRY_OR_THROW_OOM(vm, String::formatted("Lexical environment already has binding '{}'", name)));
if (is_immutable)
return vm.lexical_environment()->create_immutable_binding(vm, name, is_strict);
return vm.lexical_environment()->create_mutable_binding(vm, name, is_strict);
}
if (!is_global) {
if (is_immutable)
return vm.variable_environment()->create_immutable_binding(vm, name, is_strict);
return vm.variable_environment()->create_mutable_binding(vm, name, is_strict);
}
// NOTE: CreateVariable with m_is_global set to true is expected to only be used in GlobalDeclarationInstantiation currently, which only uses "false" for "can_be_deleted".
// The only area that sets "can_be_deleted" to true is EvalDeclarationInstantiation, which is currently fully implemented in C++ and not in Bytecode.
AK+Everywhere: Rename `verify_cast` to `as` Follow-up to fc20e61e7249006247b43f84a3189d5a37fa103e.
2025-01-21 09:12:05 -05:00
return as<GlobalEnvironment>(vm.variable_environment())->create_global_var_binding(name, false);
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
}
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
inline ThrowCompletionOr<GC::Ref<Array>> iterator_to_array(VM& vm, Value iterator)
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
{
LibJS: Make IteratorRecord inherit from Cell, not Object This shaves its size down from 104 bytes to 48 bytes, cutting GC pressure caused by this type in more than half.
2025-03-22 11:46:54 -05:00
auto& iterator_record = static_cast<IteratorRecord&>(iterator.as_cell());
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
auto array = MUST(Array::create(*vm.current_realm(), 0));
size_t index = 0;
while (true) {
auto value = TRY(iterator_step_value(vm, iterator_record));
if (!value.has_value())
return array;
MUST(array->create_data_property_or_throw(index, value.release_value()));
index++;
}
}
inline ThrowCompletionOr<void> append(VM& vm, Value lhs, Value rhs, bool is_spread)
{
// Note: This OpCode is used to construct array literals and argument arrays for calls,
// containing at least one spread element,
// Iterating over such a spread element to unpack it has to be visible by
// the user courtesy of
// (1) https://tc39.es/ecma262/#sec-runtime-semantics-arrayaccumulation
// SpreadElement : ... AssignmentExpression
// 1. Let spreadRef be ? Evaluation of AssignmentExpression.
// 2. Let spreadObj be ? GetValue(spreadRef).
// 3. Let iteratorRecord be ? GetIterator(spreadObj).
// 4. Repeat,
// a. Let next be ? IteratorStep(iteratorRecord).
// b. If next is false, return nextIndex.
// c. Let nextValue be ? IteratorValue(next).
// d. Perform ! CreateDataPropertyOrThrow(array, ! ToString(𝔽(nextIndex)), nextValue).
// e. Set nextIndex to nextIndex + 1.
// (2) https://tc39.es/ecma262/#sec-runtime-semantics-argumentlistevaluation
// ArgumentList : ... AssignmentExpression
// 1. Let list be a new empty List.
// 2. Let spreadRef be ? Evaluation of AssignmentExpression.
// 3. Let spreadObj be ? GetValue(spreadRef).
// 4. Let iteratorRecord be ? GetIterator(spreadObj).
// 5. Repeat,
// a. Let next be ? IteratorStep(iteratorRecord).
// b. If next is false, return list.
// c. Let nextArg be ? IteratorValue(next).
// d. Append nextArg to list.
// ArgumentList : ArgumentList , ... AssignmentExpression
// 1. Let precedingArgs be ? ArgumentListEvaluation of ArgumentList.
// 2. Let spreadRef be ? Evaluation of AssignmentExpression.
// 3. Let iteratorRecord be ? GetIterator(? GetValue(spreadRef)).
// 4. Repeat,
// a. Let next be ? IteratorStep(iteratorRecord).
// b. If next is false, return precedingArgs.
// c. Let nextArg be ? IteratorValue(next).
// d. Append nextArg to precedingArgs.
// Note: We know from codegen, that lhs is a plain array with only indexed properties
auto& lhs_array = lhs.as_array();
auto lhs_size = lhs_array.indexed_properties().array_like_size();
if (is_spread) {
// ...rhs
size_t i = lhs_size;
TRY(get_iterator_values(vm, rhs, [&i, &lhs_array](Value iterator_value) -> Optional<Completion> {
lhs_array.indexed_properties().put(i, iterator_value, default_attributes);
++i;
return {};
}));
} else {
lhs_array.indexed_properties().put(lhs_size, rhs, default_attributes);
}
return {};
}
LibJS: Add minimum changes to build on Windows and run js.exe This commit adds the minimal export macros needed to run js.exe on windows. A followup commit is planned to move to explicit export entirely. A static_assert for the size of a struct is also ifdef'ed out as the semantics around object layout and inheritance are different on MSVC abi and the struct IteratorRecord ends up being 40 bytes not 32.
2025-05-24 23:46:13 +02:00
class JS_API PropertyNameIterator final
LibJS: Teach for..in iterator to use IteratorNextUnpack optimization Even though this code was already optimized to re-use a single result object, returning { value, done } directly in output parameters still provides a substantial speedup. 1.21x speedup on MicroBench/for-in-indexed-properties.js
2025-05-03 10:17:11 +02:00
: public Object
, public BuiltinIterator {
JS_OBJECT(PropertyNameIterator, Object);
GC_DECLARE_ALLOCATOR(PropertyNameIterator);
public:
virtual ~PropertyNameIterator() override = default;
LibJS: Avoid `IteratorRecord` GC-allocation in `GetIterator` instruction With this change, `GetIterator` no longer GC-allocates an `IteratorRecord`. Instead, it stores the iterator record fields in bytecode registers. This avoids per-iteration allocations in patterns like: `for (let [x] of array) {}`. `IteratorRecord` now inherits from `IteratorRecordImpl`, which holds the iteration state. This allows the existing iteration helpers (`iterator_next()`, `iterator_step()`, etc.) operate on both the GC-allocated and the register-backed forms. Microbenchmarks: 1.1x array-destructuring-assignment-rest.js 1.226x array-destructuring-assignment.js
2025-10-27 19:46:54 +01:00
BuiltinIterator* as_builtin_iterator_if_next_is_not_redefined(Value) override { return this; }
LibJS: Fast-path own-property enumeration and reduce descriptor lookups Before this change, PropertyNameIterator (used by for..in) and `Object::enumerable_own_property_names()` (used by `Object.keys()`, `Object.values()`, and `Object.entries()`) enumerated an object's own enumerable properties exactly as the spec prescribes: - Call `internal_own_property_keys()`, allocating a list of JS::Value keys. - For each key, call internal_get_own_property() to obtain a descriptor and check `[[Enumerable]]`. While that is required in the general case (e.g. for Proxy objects or platform/exotic objects that override `[[OwnPropertyKeys]]`), it's overkill for ordinary JS objects that store their own properties in the shape table and indexed-properties storage. This change introduces `for_each_own_property_with_enumerability()`, which, for objects where `eligible_for_own_property_enumeration_fast_path()` is `true`, lets us read the enumerability directly from shape metadata (and from indexed-properties storage) without a per-property descriptor lookup. When we cannot avoid `internal_get_own_property()`, we still benefit by skipping the temporary `Vector<Value>` of keys and avoiding the unnecessary round-trip between PropertyKey and Value.
2025-09-19 16:49:53 +02:00
ThrowCompletionOr<void> next(VM& vm, bool& done, Value& value) override
LibJS: Teach for..in iterator to use IteratorNextUnpack optimization Even though this code was already optimized to re-use a single result object, returning { value, done } directly in output parameters still provides a substantial speedup. 1.21x speedup on MicroBench/for-in-indexed-properties.js
2025-05-03 10:17:11 +02:00
{
while (true) {
LibJS: Don't incrementally delete PropertyNameIterator while iterating We were spending a lot of time removing each property name from the iterator's underlying HashMap while iterating over it. This wasn't actually necessary, so let's stop doing it and instead just iterate over the property names with a stored HashTable iterator. 1.10x speedup on MicroBench/for-in-indexed-properties.js
2025-05-03 21:12:00 +02:00
if (m_iterator == m_properties.end()) {
LibJS: Teach for..in iterator to use IteratorNextUnpack optimization Even though this code was already optimized to re-use a single result object, returning { value, done } directly in output parameters still provides a substantial speedup. 1.21x speedup on MicroBench/for-in-indexed-properties.js
2025-05-03 10:17:11 +02:00
done = true;
return {};
}
LibJS: Don't incrementally delete PropertyNameIterator while iterating We were spending a lot of time removing each property name from the iterator's underlying HashMap while iterating over it. This wasn't actually necessary, so let's stop doing it and instead just iterate over the property names with a stored HashTable iterator. 1.10x speedup on MicroBench/for-in-indexed-properties.js
2025-05-03 21:12:00 +02:00
auto const& entry = *m_iterator;
ScopeGuard remove_first = [&] { ++m_iterator; };
LibJS: Teach for..in iterator to use IteratorNextUnpack optimization Even though this code was already optimized to re-use a single result object, returning { value, done } directly in output parameters still provides a substantial speedup. 1.21x speedup on MicroBench/for-in-indexed-properties.js
2025-05-03 10:17:11 +02:00
// If the property is deleted, don't include it (invariant no. 2)
LibJS: Optimize keys deduplication in `get_object_property_iterator()` This change implements a part responsible for this invariant in a more efficient way: "Enumerating the properties of the target object includes enumerating properties of its prototype, and the prototype of the prototype, and so on, recursively; but a property of a prototype is not processed if it has the same name as a property that has already been processed by the iterator's next method." Previously we inserted `(key, enumerable)` pairs into an `OrderedHashTable`. That always built and maintained a hash table, even when no prototype-level filtering was needed. Now we: - Collect only enumerable keys into `Vector<PropertyKey>`. - Track `seen_non_enumerable_properties` so a non-enumerable own property still shadows prototype properties with the same name. - Lazily materialize `HashTable<PropertyKey>` only if we encounter an enumerable property on a prototype and must check for duplicates. In the common case materialization is avoided, because default Object or Array prototype properties are non-enumerable.
2025-09-20 19:16:31 +02:00
if (!TRY(m_object->has_property(entry)))
LibJS: Teach for..in iterator to use IteratorNextUnpack optimization Even though this code was already optimized to re-use a single result object, returning { value, done } directly in output parameters still provides a substantial speedup. 1.21x speedup on MicroBench/for-in-indexed-properties.js
2025-05-03 10:17:11 +02:00
continue;
done = false;
LibJS: Optimize keys deduplication in `get_object_property_iterator()` This change implements a part responsible for this invariant in a more efficient way: "Enumerating the properties of the target object includes enumerating properties of its prototype, and the prototype of the prototype, and so on, recursively; but a property of a prototype is not processed if it has the same name as a property that has already been processed by the iterator's next method." Previously we inserted `(key, enumerable)` pairs into an `OrderedHashTable`. That always built and maintained a hash table, even when no prototype-level filtering was needed. Now we: - Collect only enumerable keys into `Vector<PropertyKey>`. - Track `seen_non_enumerable_properties` so a non-enumerable own property still shadows prototype properties with the same name. - Lazily materialize `HashTable<PropertyKey>` only if we encounter an enumerable property on a prototype and must check for duplicates. In the common case materialization is avoided, because default Object or Array prototype properties are non-enumerable.
2025-09-20 19:16:31 +02:00
value = entry.to_value(vm);
LibJS: Teach for..in iterator to use IteratorNextUnpack optimization Even though this code was already optimized to re-use a single result object, returning { value, done } directly in output parameters still provides a substantial speedup. 1.21x speedup on MicroBench/for-in-indexed-properties.js
2025-05-03 10:17:11 +02:00
return {};
}
}
private:
LibJS: Optimize keys deduplication in `get_object_property_iterator()` This change implements a part responsible for this invariant in a more efficient way: "Enumerating the properties of the target object includes enumerating properties of its prototype, and the prototype of the prototype, and so on, recursively; but a property of a prototype is not processed if it has the same name as a property that has already been processed by the iterator's next method." Previously we inserted `(key, enumerable)` pairs into an `OrderedHashTable`. That always built and maintained a hash table, even when no prototype-level filtering was needed. Now we: - Collect only enumerable keys into `Vector<PropertyKey>`. - Track `seen_non_enumerable_properties` so a non-enumerable own property still shadows prototype properties with the same name. - Lazily materialize `HashTable<PropertyKey>` only if we encounter an enumerable property on a prototype and must check for duplicates. In the common case materialization is avoided, because default Object or Array prototype properties are non-enumerable.
2025-09-20 19:16:31 +02:00
PropertyNameIterator(JS::Realm& realm, GC::Ref<Object> object, Vector<PropertyKey> properties)
LibJS: Teach for..in iterator to use IteratorNextUnpack optimization Even though this code was already optimized to re-use a single result object, returning { value, done } directly in output parameters still provides a substantial speedup. 1.21x speedup on MicroBench/for-in-indexed-properties.js
2025-05-03 10:17:11 +02:00
: Object(realm, nullptr)
, m_object(object)
, m_properties(move(properties))
LibJS: Don't incrementally delete PropertyNameIterator while iterating We were spending a lot of time removing each property name from the iterator's underlying HashMap while iterating over it. This wasn't actually necessary, so let's stop doing it and instead just iterate over the property names with a stored HashTable iterator. 1.10x speedup on MicroBench/for-in-indexed-properties.js
2025-05-03 21:12:00 +02:00
, m_iterator(m_properties.begin())
LibJS: Teach for..in iterator to use IteratorNextUnpack optimization Even though this code was already optimized to re-use a single result object, returning { value, done } directly in output parameters still provides a substantial speedup. 1.21x speedup on MicroBench/for-in-indexed-properties.js
2025-05-03 10:17:11 +02:00
{
}
virtual void visit_edges(Visitor& visitor) override
{
Base::visit_edges(visitor);
visitor.visit(m_object);
LibJS+LibWeb: Add missing GC marking visits This adds visit_edges(Cell::Visitor&) methods to various helper structs that contain GC pointers, and makes sure they are called from owning GC-heap-allocated objects as needed. These were found by our Clang plugin after expanding its capabilities. The added rules will be enforced by CI going forward.
2026-01-06 00:36:34 +01:00
for (auto& key : m_properties)
key.visit_edges(visitor);
if (!m_iterator.is_end())
m_iterator->visit_edges(visitor);
LibJS: Teach for..in iterator to use IteratorNextUnpack optimization Even though this code was already optimized to re-use a single result object, returning { value, done } directly in output parameters still provides a substantial speedup. 1.21x speedup on MicroBench/for-in-indexed-properties.js
2025-05-03 10:17:11 +02:00
}
GC::Ref<Object> m_object;
LibJS: Optimize keys deduplication in `get_object_property_iterator()` This change implements a part responsible for this invariant in a more efficient way: "Enumerating the properties of the target object includes enumerating properties of its prototype, and the prototype of the prototype, and so on, recursively; but a property of a prototype is not processed if it has the same name as a property that has already been processed by the iterator's next method." Previously we inserted `(key, enumerable)` pairs into an `OrderedHashTable`. That always built and maintained a hash table, even when no prototype-level filtering was needed. Now we: - Collect only enumerable keys into `Vector<PropertyKey>`. - Track `seen_non_enumerable_properties` so a non-enumerable own property still shadows prototype properties with the same name. - Lazily materialize `HashTable<PropertyKey>` only if we encounter an enumerable property on a prototype and must check for duplicates. In the common case materialization is avoided, because default Object or Array prototype properties are non-enumerable.
2025-09-20 19:16:31 +02:00
Vector<PropertyKey> m_properties;
LibJS: Don't incrementally delete PropertyNameIterator while iterating We were spending a lot of time removing each property name from the iterator's underlying HashMap while iterating over it. This wasn't actually necessary, so let's stop doing it and instead just iterate over the property names with a stored HashTable iterator. 1.10x speedup on MicroBench/for-in-indexed-properties.js
2025-05-03 21:12:00 +02:00
decltype(m_properties.begin()) m_iterator;
LibJS: Teach for..in iterator to use IteratorNextUnpack optimization Even though this code was already optimized to re-use a single result object, returning { value, done } directly in output parameters still provides a substantial speedup. 1.21x speedup on MicroBench/for-in-indexed-properties.js
2025-05-03 10:17:11 +02:00
};
GC_DEFINE_ALLOCATOR(PropertyNameIterator);
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
// 14.7.5.9 EnumerateObjectProperties ( O ), https://tc39.es/ecma262/#sec-enumerate-object-properties
LibJS: Avoid `IteratorRecord` GC-allocation in `GetIterator` instruction With this change, `GetIterator` no longer GC-allocates an `IteratorRecord`. Instead, it stores the iterator record fields in bytecode registers. This avoids per-iteration allocations in patterns like: `for (let [x] of array) {}`. `IteratorRecord` now inherits from `IteratorRecordImpl`, which holds the iteration state. This allows the existing iteration helpers (`iterator_next()`, `iterator_step()`, etc.) operate on both the GC-allocated and the register-backed forms. Microbenchmarks: 1.1x array-destructuring-assignment-rest.js 1.226x array-destructuring-assignment.js
2025-10-27 19:46:54 +01:00
inline ThrowCompletionOr<IteratorRecordImpl> get_object_property_iterator(Interpreter& interpreter, Value value)
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
{
// While the spec does provide an algorithm, it allows us to implement it ourselves so long as we meet the following invariants:
// 1- Returned property keys do not include keys that are Symbols
// 2- Properties of the target object may be deleted during enumeration. A property that is deleted before it is processed by the iterator's next method is ignored
// 3- If new properties are added to the target object during enumeration, the newly added properties are not guaranteed to be processed in the active enumeration
// 4- A property name will be returned by the iterator's next method at most once in any enumeration.
// 5- Enumerating the properties of the target object includes enumerating properties of its prototype, and the prototype of the prototype, and so on, recursively;
// but a property of a prototype is not processed if it has the same name as a property that has already been processed by the iterator's next method.
// 6- The values of [[Enumerable]] attributes are not considered when determining if a property of a prototype object has already been processed.
// 7- The enumerable property names of prototype objects must be obtained by invoking EnumerateObjectProperties passing the prototype object as the argument.
// 8- EnumerateObjectProperties must obtain the own property keys of the target object by calling its [[OwnPropertyKeys]] internal method.
// 9- Property attributes of the target object must be obtained by calling its [[GetOwnProperty]] internal method
LibJS: Teach for..in iterator to use IteratorNextUnpack optimization Even though this code was already optimized to re-use a single result object, returning { value, done } directly in output parameters still provides a substantial speedup. 1.21x speedup on MicroBench/for-in-indexed-properties.js
2025-05-03 10:17:11 +02:00
auto& vm = interpreter.vm();
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
// Invariant 3 effectively allows the implementation to ignore newly added keys, and we do so (similar to other implementations).
auto object = TRY(value.to_object(vm));
// Note: While the spec doesn't explicitly require these to be ordered, it says that the values should be retrieved via OwnPropertyKeys,
// so we just keep the order consistent anyway.
LibJS: Do a single pass to prune non-enumerable keys for iteration Instead of pruning as-we-go, which means a ton of hash lookups, we now only do a single pass to prune all non-enumerable keys when setting up for for..in iteration.
2025-03-19 17:08:24 -05:00
LibJS: Fast-path own-property enumeration and reduce descriptor lookups Before this change, PropertyNameIterator (used by for..in) and `Object::enumerable_own_property_names()` (used by `Object.keys()`, `Object.values()`, and `Object.entries()`) enumerated an object's own enumerable properties exactly as the spec prescribes: - Call `internal_own_property_keys()`, allocating a list of JS::Value keys. - For each key, call internal_get_own_property() to obtain a descriptor and check `[[Enumerable]]`. While that is required in the general case (e.g. for Proxy objects or platform/exotic objects that override `[[OwnPropertyKeys]]`), it's overkill for ordinary JS objects that store their own properties in the shape table and indexed-properties storage. This change introduces `for_each_own_property_with_enumerability()`, which, for objects where `eligible_for_own_property_enumeration_fast_path()` is `true`, lets us read the enumerability directly from shape metadata (and from indexed-properties storage) without a per-property descriptor lookup. When we cannot avoid `internal_get_own_property()`, we still benefit by skipping the temporary `Vector<Value>` of keys and avoiding the unnecessary round-trip between PropertyKey and Value.
2025-09-19 16:49:53 +02:00
size_t estimated_properties_count = 0;
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
HashTable<GC::Ref<Object>> seen_objects;
for (auto object_to_check = GC::Ptr { object.ptr() }; object_to_check && !seen_objects.contains(*object_to_check); object_to_check = TRY(object_to_check->internal_get_prototype_of())) {
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
seen_objects.set(*object_to_check);
LibJS: Fast-path own-property enumeration and reduce descriptor lookups Before this change, PropertyNameIterator (used by for..in) and `Object::enumerable_own_property_names()` (used by `Object.keys()`, `Object.values()`, and `Object.entries()`) enumerated an object's own enumerable properties exactly as the spec prescribes: - Call `internal_own_property_keys()`, allocating a list of JS::Value keys. - For each key, call internal_get_own_property() to obtain a descriptor and check `[[Enumerable]]`. While that is required in the general case (e.g. for Proxy objects or platform/exotic objects that override `[[OwnPropertyKeys]]`), it's overkill for ordinary JS objects that store their own properties in the shape table and indexed-properties storage. This change introduces `for_each_own_property_with_enumerability()`, which, for objects where `eligible_for_own_property_enumeration_fast_path()` is `true`, lets us read the enumerability directly from shape metadata (and from indexed-properties storage) without a per-property descriptor lookup. When we cannot avoid `internal_get_own_property()`, we still benefit by skipping the temporary `Vector<Value>` of keys and avoiding the unnecessary round-trip between PropertyKey and Value.
2025-09-19 16:49:53 +02:00
estimated_properties_count += object_to_check->own_properties_count();
}
seen_objects.clear_with_capacity();
LibJS: Optimize keys deduplication in `get_object_property_iterator()` This change implements a part responsible for this invariant in a more efficient way: "Enumerating the properties of the target object includes enumerating properties of its prototype, and the prototype of the prototype, and so on, recursively; but a property of a prototype is not processed if it has the same name as a property that has already been processed by the iterator's next method." Previously we inserted `(key, enumerable)` pairs into an `OrderedHashTable`. That always built and maintained a hash table, even when no prototype-level filtering was needed. Now we: - Collect only enumerable keys into `Vector<PropertyKey>`. - Track `seen_non_enumerable_properties` so a non-enumerable own property still shadows prototype properties with the same name. - Lazily materialize `HashTable<PropertyKey>` only if we encounter an enumerable property on a prototype and must check for duplicates. In the common case materialization is avoided, because default Object or Array prototype properties are non-enumerable.
2025-09-20 19:16:31 +02:00
Vector<PropertyKey> properties;
LibJS: Fast-path own-property enumeration and reduce descriptor lookups Before this change, PropertyNameIterator (used by for..in) and `Object::enumerable_own_property_names()` (used by `Object.keys()`, `Object.values()`, and `Object.entries()`) enumerated an object's own enumerable properties exactly as the spec prescribes: - Call `internal_own_property_keys()`, allocating a list of JS::Value keys. - For each key, call internal_get_own_property() to obtain a descriptor and check `[[Enumerable]]`. While that is required in the general case (e.g. for Proxy objects or platform/exotic objects that override `[[OwnPropertyKeys]]`), it's overkill for ordinary JS objects that store their own properties in the shape table and indexed-properties storage. This change introduces `for_each_own_property_with_enumerability()`, which, for objects where `eligible_for_own_property_enumeration_fast_path()` is `true`, lets us read the enumerability directly from shape metadata (and from indexed-properties storage) without a per-property descriptor lookup. When we cannot avoid `internal_get_own_property()`, we still benefit by skipping the temporary `Vector<Value>` of keys and avoiding the unnecessary round-trip between PropertyKey and Value.
2025-09-19 16:49:53 +02:00
properties.ensure_capacity(estimated_properties_count);
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
LibJS: Optimize keys deduplication in `get_object_property_iterator()` This change implements a part responsible for this invariant in a more efficient way: "Enumerating the properties of the target object includes enumerating properties of its prototype, and the prototype of the prototype, and so on, recursively; but a property of a prototype is not processed if it has the same name as a property that has already been processed by the iterator's next method." Previously we inserted `(key, enumerable)` pairs into an `OrderedHashTable`. That always built and maintained a hash table, even when no prototype-level filtering was needed. Now we: - Collect only enumerable keys into `Vector<PropertyKey>`. - Track `seen_non_enumerable_properties` so a non-enumerable own property still shadows prototype properties with the same name. - Lazily materialize `HashTable<PropertyKey>` only if we encounter an enumerable property on a prototype and must check for duplicates. In the common case materialization is avoided, because default Object or Array prototype properties are non-enumerable.
2025-09-20 19:16:31 +02:00
HashTable<PropertyKey> seen_non_enumerable_properties;
Optional<HashTable<PropertyKey>> seen_properties;
auto ensure_seen_properties = [&] {
if (seen_properties.has_value())
return;
seen_properties = HashTable<PropertyKey> {};
seen_properties->ensure_capacity(properties.size());
for (auto const& property : properties)
seen_properties->set(property);
};
LibJS: Fast-path own-property enumeration and reduce descriptor lookups Before this change, PropertyNameIterator (used by for..in) and `Object::enumerable_own_property_names()` (used by `Object.keys()`, `Object.values()`, and `Object.entries()`) enumerated an object's own enumerable properties exactly as the spec prescribes: - Call `internal_own_property_keys()`, allocating a list of JS::Value keys. - For each key, call internal_get_own_property() to obtain a descriptor and check `[[Enumerable]]`. While that is required in the general case (e.g. for Proxy objects or platform/exotic objects that override `[[OwnPropertyKeys]]`), it's overkill for ordinary JS objects that store their own properties in the shape table and indexed-properties storage. This change introduces `for_each_own_property_with_enumerability()`, which, for objects where `eligible_for_own_property_enumeration_fast_path()` is `true`, lets us read the enumerability directly from shape metadata (and from indexed-properties storage) without a per-property descriptor lookup. When we cannot avoid `internal_get_own_property()`, we still benefit by skipping the temporary `Vector<Value>` of keys and avoiding the unnecessary round-trip between PropertyKey and Value.
2025-09-19 16:49:53 +02:00
// Collect all keys immediately (invariant no. 5)
LibJS: Optimize keys deduplication in `get_object_property_iterator()` This change implements a part responsible for this invariant in a more efficient way: "Enumerating the properties of the target object includes enumerating properties of its prototype, and the prototype of the prototype, and so on, recursively; but a property of a prototype is not processed if it has the same name as a property that has already been processed by the iterator's next method." Previously we inserted `(key, enumerable)` pairs into an `OrderedHashTable`. That always built and maintained a hash table, even when no prototype-level filtering was needed. Now we: - Collect only enumerable keys into `Vector<PropertyKey>`. - Track `seen_non_enumerable_properties` so a non-enumerable own property still shadows prototype properties with the same name. - Lazily materialize `HashTable<PropertyKey>` only if we encounter an enumerable property on a prototype and must check for duplicates. In the common case materialization is avoided, because default Object or Array prototype properties are non-enumerable.
2025-09-20 19:16:31 +02:00
bool in_prototype_chain = false;
LibJS: Fast-path own-property enumeration and reduce descriptor lookups Before this change, PropertyNameIterator (used by for..in) and `Object::enumerable_own_property_names()` (used by `Object.keys()`, `Object.values()`, and `Object.entries()`) enumerated an object's own enumerable properties exactly as the spec prescribes: - Call `internal_own_property_keys()`, allocating a list of JS::Value keys. - For each key, call internal_get_own_property() to obtain a descriptor and check `[[Enumerable]]`. While that is required in the general case (e.g. for Proxy objects or platform/exotic objects that override `[[OwnPropertyKeys]]`), it's overkill for ordinary JS objects that store their own properties in the shape table and indexed-properties storage. This change introduces `for_each_own_property_with_enumerability()`, which, for objects where `eligible_for_own_property_enumeration_fast_path()` is `true`, lets us read the enumerability directly from shape metadata (and from indexed-properties storage) without a per-property descriptor lookup. When we cannot avoid `internal_get_own_property()`, we still benefit by skipping the temporary `Vector<Value>` of keys and avoiding the unnecessary round-trip between PropertyKey and Value.
2025-09-19 16:49:53 +02:00
for (auto object_to_check = GC::Ptr { object.ptr() }; object_to_check && !seen_objects.contains(*object_to_check); object_to_check = TRY(object_to_check->internal_get_prototype_of())) {
seen_objects.set(*object_to_check);
TRY(object_to_check->for_each_own_property_with_enumerability([&](PropertyKey const& property_key, bool enumerable) -> ThrowCompletionOr<void> {
LibJS: Optimize keys deduplication in `get_object_property_iterator()` This change implements a part responsible for this invariant in a more efficient way: "Enumerating the properties of the target object includes enumerating properties of its prototype, and the prototype of the prototype, and so on, recursively; but a property of a prototype is not processed if it has the same name as a property that has already been processed by the iterator's next method." Previously we inserted `(key, enumerable)` pairs into an `OrderedHashTable`. That always built and maintained a hash table, even when no prototype-level filtering was needed. Now we: - Collect only enumerable keys into `Vector<PropertyKey>`. - Track `seen_non_enumerable_properties` so a non-enumerable own property still shadows prototype properties with the same name. - Lazily materialize `HashTable<PropertyKey>` only if we encounter an enumerable property on a prototype and must check for duplicates. In the common case materialization is avoided, because default Object or Array prototype properties are non-enumerable.
2025-09-20 19:16:31 +02:00
if (!enumerable)
seen_non_enumerable_properties.set(property_key);
if (in_prototype_chain && enumerable) {
if (seen_non_enumerable_properties.contains(property_key))
return {};
ensure_seen_properties();
if (seen_properties->contains(property_key))
return {};
}
if (enumerable)
properties.append(property_key);
if (seen_properties.has_value())
seen_properties->set(property_key);
LibJS: Fast-path own-property enumeration and reduce descriptor lookups Before this change, PropertyNameIterator (used by for..in) and `Object::enumerable_own_property_names()` (used by `Object.keys()`, `Object.values()`, and `Object.entries()`) enumerated an object's own enumerable properties exactly as the spec prescribes: - Call `internal_own_property_keys()`, allocating a list of JS::Value keys. - For each key, call internal_get_own_property() to obtain a descriptor and check `[[Enumerable]]`. While that is required in the general case (e.g. for Proxy objects or platform/exotic objects that override `[[OwnPropertyKeys]]`), it's overkill for ordinary JS objects that store their own properties in the shape table and indexed-properties storage. This change introduces `for_each_own_property_with_enumerability()`, which, for objects where `eligible_for_own_property_enumeration_fast_path()` is `true`, lets us read the enumerability directly from shape metadata (and from indexed-properties storage) without a per-property descriptor lookup. When we cannot avoid `internal_get_own_property()`, we still benefit by skipping the temporary `Vector<Value>` of keys and avoiding the unnecessary round-trip between PropertyKey and Value.
2025-09-19 16:49:53 +02:00
return {};
}));
LibJS: Optimize keys deduplication in `get_object_property_iterator()` This change implements a part responsible for this invariant in a more efficient way: "Enumerating the properties of the target object includes enumerating properties of its prototype, and the prototype of the prototype, and so on, recursively; but a property of a prototype is not processed if it has the same name as a property that has already been processed by the iterator's next method." Previously we inserted `(key, enumerable)` pairs into an `OrderedHashTable`. That always built and maintained a hash table, even when no prototype-level filtering was needed. Now we: - Collect only enumerable keys into `Vector<PropertyKey>`. - Track `seen_non_enumerable_properties` so a non-enumerable own property still shadows prototype properties with the same name. - Lazily materialize `HashTable<PropertyKey>` only if we encounter an enumerable property on a prototype and must check for duplicates. In the common case materialization is avoided, because default Object or Array prototype properties are non-enumerable.
2025-09-20 19:16:31 +02:00
in_prototype_chain = true;
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
}
LibJS: Do a single pass to prune non-enumerable keys for iteration Instead of pruning as-we-go, which means a ton of hash lookups, we now only do a single pass to prune all non-enumerable keys when setting up for for..in iteration.
2025-03-19 17:08:24 -05:00
LibJS: Teach for..in iterator to use IteratorNextUnpack optimization Even though this code was already optimized to re-use a single result object, returning { value, done } directly in output parameters still provides a substantial speedup. 1.21x speedup on MicroBench/for-in-indexed-properties.js
2025-05-03 10:17:11 +02:00
auto iterator = interpreter.realm().create<PropertyNameIterator>(interpreter.realm(), object, move(properties));
LibJS: Avoid `IteratorRecord` GC-allocation in `GetIterator` instruction With this change, `GetIterator` no longer GC-allocates an `IteratorRecord`. Instead, it stores the iterator record fields in bytecode registers. This avoids per-iteration allocations in patterns like: `for (let [x] of array) {}`. `IteratorRecord` now inherits from `IteratorRecordImpl`, which holds the iteration state. This allows the existing iteration helpers (`iterator_next()`, `iterator_step()`, etc.) operate on both the GC-allocated and the register-backed forms. Microbenchmarks: 1.1x array-destructuring-assignment-rest.js 1.226x array-destructuring-assignment.js
2025-10-27 19:46:54 +01:00
return IteratorRecordImpl { .done = false, .iterator = iterator, .next_method = js_undefined() };
LibJS: Move CommonImplementations.h into Interpreter.cpp Now that the Interpreter is the only user of these functions, we might as well keep them in Interpreter.cpp which makes CLion less confused.
2024-07-09 10:10:14 +02:00
}
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
ByteString Instruction::to_byte_string(Bytecode::Executable const& executable) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
#define __BYTECODE_OP(op) \
case Instruction::Type::op: \
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
return static_cast<Bytecode::Op::op const&>(*this).to_byte_string_impl(executable);
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
switch (type()) {
ENUMERATE_BYTECODE_OPS(__BYTECODE_OP)
default:
VERIFY_NOT_REACHED();
}
#undef __BYTECODE_OP
}
}
namespace JS::Bytecode::Op {
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
#define JS_DEFINE_EXECUTE_FOR_COMMON_BINARY_OP(OpTitleCase, op_snake_case) \
ThrowCompletionOr<void> OpTitleCase::execute_impl(Bytecode::Interpreter& interpreter) const \
{ \
auto& vm = interpreter.vm(); \
auto lhs = interpreter.get(m_lhs); \
auto rhs = interpreter.get(m_rhs); \
LibJS: Avoid roundtrip through Value for comparison bytecode evaluation 1.1x speedup on strictly-equals-object.js
2025-05-08 15:19:35 +12:00
interpreter.set(m_dst, Value { TRY(op_snake_case(vm, lhs, rhs)) }); \
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
return {}; \
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
JS_ENUMERATE_COMMON_BINARY_OPS_WITHOUT_FAST_PATH(JS_DEFINE_EXECUTE_FOR_COMMON_BINARY_OP)
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> Add::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
{
auto& vm = interpreter.vm();
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto const lhs = interpreter.get(m_lhs);
auto const rhs = interpreter.get(m_rhs);
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
LibJS: Mark more interpreter fast paths [[likely]] Let's assume arithmetic and comparison operators are mostly being used on numbers.
2025-12-04 22:26:22 +01:00
if (lhs.is_number() && rhs.is_number()) [[likely]] {
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
if (lhs.is_int32() && rhs.is_int32()) {
LibJS: Mark Int32 overflow in interpreter fast paths [[unlikely]]
2025-12-04 21:58:41 +01:00
if (!Checked<i32>::addition_would_overflow(lhs.as_i32(), rhs.as_i32())) [[likely]] {
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, Value(lhs.as_i32() + rhs.as_i32()));
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
return {};
}
LibJS: Make overflowing arithmetic on 2x Int32 values faster Instead of converting them to doubles and doing double math, just do the arithmetic operation in i64 space instead. This gives us a ~1.25x speed-up on this kind of micro-benchmark: (() => { let a = -2124299999; for (let i = 0; i < 100_000_000; ++i) { a + a; } })() Same idea for Add, Sub, and Mul. There's a fair bit of overflowing Int32 arithmetic in some of the JetStream benchmarks, and this seems like an obvious improvement.
2025-10-07 12:08:06 +02:00
auto result = static_cast<i64>(lhs.as_i32()) + static_cast<i64>(rhs.as_i32());
interpreter.set(m_dst, Value(result, Value::CannotFitInInt32::Indeed));
return {};
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, Value(lhs.as_double() + rhs.as_double()));
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, TRY(add(vm, lhs, rhs)));
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> Mul::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
{
auto& vm = interpreter.vm();
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto const lhs = interpreter.get(m_lhs);
auto const rhs = interpreter.get(m_rhs);
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
LibJS: Mark more interpreter fast paths [[likely]] Let's assume arithmetic and comparison operators are mostly being used on numbers.
2025-12-04 22:26:22 +01:00
if (lhs.is_number() && rhs.is_number()) [[likely]] {
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
if (lhs.is_int32() && rhs.is_int32()) {
LibJS: Mark Int32 overflow in interpreter fast paths [[unlikely]]
2025-12-04 21:58:41 +01:00
if (!Checked<i32>::multiplication_would_overflow(lhs.as_i32(), rhs.as_i32())) [[likely]] {
LibJS: Produce negative zero from i32 multiplication fast path The i32 multiplication fast path in Mul::execute_impl was producing +0 instead of -0 when one operand was negative and the other was zero (e.g. `var a = -1, b = 0; a * b`). This happened because i32 can't represent -0, so `Value(0)` was always positive zero. We now fall through to the double path when the i32 result is zero, which correctly handles the sign. Also add comprehensive multiplication tests covering negative zero, basic arithmetic, large integers, type coercion, NaN, and Infinity.
2026-02-08 11:32:14 +01:00
auto lhs_i32 = lhs.as_i32();
auto rhs_i32 = rhs.as_i32();
auto result = lhs_i32 * rhs_i32;
if (result != 0) [[likely]] {
interpreter.set(m_dst, Value(result));
return {};
}
// NB: When the mathematical result is zero, the sign depends on the operand
// signs. We can determine it directly here instead of widening to double.
auto is_negative_zero = (lhs_i32 < 0) != (rhs_i32 < 0);
interpreter.set(m_dst, is_negative_zero ? Value(-0.0) : Value(0));
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
return {};
}
LibJS: Make overflowing arithmetic on 2x Int32 values faster Instead of converting them to doubles and doing double math, just do the arithmetic operation in i64 space instead. This gives us a ~1.25x speed-up on this kind of micro-benchmark: (() => { let a = -2124299999; for (let i = 0; i < 100_000_000; ++i) { a + a; } })() Same idea for Add, Sub, and Mul. There's a fair bit of overflowing Int32 arithmetic in some of the JetStream benchmarks, and this seems like an obvious improvement.
2025-10-07 12:08:06 +02:00
auto result = static_cast<i64>(lhs.as_i32()) * static_cast<i64>(rhs.as_i32());
interpreter.set(m_dst, Value(result, Value::CannotFitInInt32::Indeed));
return {};
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, Value(lhs.as_double() * rhs.as_double()));
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, TRY(mul(vm, lhs, rhs)));
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
return {};
}
LibJS: Add fast path for division of two numbers We already had fast paths for Add, Sub and Mul. Might as well do Div. 1.18x speed-up on this micro-benchmark: (() => { let a = 1234; for (let i = 0; i < 100_000_000; ++i) a / a; })()
2025-10-11 17:33:34 +02:00
ThrowCompletionOr<void> Div::execute_impl(Bytecode::Interpreter& interpreter) const
{
auto& vm = interpreter.vm();
auto const lhs = interpreter.get(m_lhs);
auto const rhs = interpreter.get(m_rhs);
if (lhs.is_number() && rhs.is_number()) [[likely]] {
interpreter.set(m_dst, Value(lhs.as_double() / rhs.as_double()));
return {};
}
interpreter.set(m_dst, TRY(div(vm, lhs, rhs)));
return {};
}
LibJS: Add % (modulo) fast path in bytecode interpreter We can avoid the expensive call to fmod() in various cases when we have Int32 values on both sides of the operator.
2026-01-08 23:46:59 +01:00
ThrowCompletionOr<void> Mod::execute_impl(Bytecode::Interpreter& interpreter) const
{
auto& vm = interpreter.vm();
auto const lhs = interpreter.get(m_lhs);
auto const rhs = interpreter.get(m_rhs);
if (lhs.is_number() && rhs.is_number()) [[likely]] {
if (lhs.is_int32() && rhs.is_int32()) {
auto n = lhs.as_i32();
auto d = rhs.as_i32();
if (d == 0) {
interpreter.set(m_dst, js_nan());
return {};
}
if (n == NumericLimits<i32>::min() && d == -1) {
interpreter.set(m_dst, Value(-0.0));
return {};
}
auto result = n % d;
if (result == 0 && n < 0) {
interpreter.set(m_dst, Value(-0.0));
return {};
}
interpreter.set(m_dst, Value(result));
return {};
}
interpreter.set(m_dst, Value(fmod(lhs.as_double(), rhs.as_double())));
return {};
}
interpreter.set(m_dst, TRY(mod(vm, lhs, rhs)));
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> Sub::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
{
auto& vm = interpreter.vm();
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto const lhs = interpreter.get(m_lhs);
auto const rhs = interpreter.get(m_rhs);
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
LibJS: Mark more interpreter fast paths [[likely]] Let's assume arithmetic and comparison operators are mostly being used on numbers.
2025-12-04 22:26:22 +01:00
if (lhs.is_number() && rhs.is_number()) [[likely]] {
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
if (lhs.is_int32() && rhs.is_int32()) {
LibJS: Mark Int32 overflow in interpreter fast paths [[unlikely]]
2025-12-04 21:58:41 +01:00
if (!Checked<i32>::subtraction_would_overflow(lhs.as_i32(), rhs.as_i32())) [[likely]] {
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, Value(lhs.as_i32() - rhs.as_i32()));
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
return {};
}
LibJS: Make overflowing arithmetic on 2x Int32 values faster Instead of converting them to doubles and doing double math, just do the arithmetic operation in i64 space instead. This gives us a ~1.25x speed-up on this kind of micro-benchmark: (() => { let a = -2124299999; for (let i = 0; i < 100_000_000; ++i) { a + a; } })() Same idea for Add, Sub, and Mul. There's a fair bit of overflowing Int32 arithmetic in some of the JetStream benchmarks, and this seems like an obvious improvement.
2025-10-07 12:08:06 +02:00
auto result = static_cast<i64>(lhs.as_i32()) - static_cast<i64>(rhs.as_i32());
interpreter.set(m_dst, Value(result, Value::CannotFitInInt32::Indeed));
return {};
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, Value(lhs.as_double() - rhs.as_double()));
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, TRY(sub(vm, lhs, rhs)));
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> BitwiseXor::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
{
auto& vm = interpreter.vm();
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto const lhs = interpreter.get(m_lhs);
auto const rhs = interpreter.get(m_rhs);
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
if (lhs.is_int32() && rhs.is_int32()) {
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, Value(lhs.as_i32() ^ rhs.as_i32()));
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, TRY(bitwise_xor(vm, lhs, rhs)));
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> BitwiseAnd::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
{
auto& vm = interpreter.vm();
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto const lhs = interpreter.get(m_lhs);
auto const rhs = interpreter.get(m_rhs);
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
if (lhs.is_int32() && rhs.is_int32()) {
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, Value(lhs.as_i32() & rhs.as_i32()));
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, TRY(bitwise_and(vm, lhs, rhs)));
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
return {};
}
LibJS: Add dedicated bytecode instruction for x|0 (ToInt32) This operation is a very common technique to force a value to become a 32-bit integer.
2025-12-15 00:14:15 -06:00
ThrowCompletionOr<void> ToInt32::execute_impl(Bytecode::Interpreter& interpreter) const
{
auto& vm = interpreter.vm();
auto const value = interpreter.get(m_value);
if (value.is_int32()) [[likely]] {
interpreter.set(m_dst, value);
return {};
}
interpreter.set(m_dst, Value(TRY(value.to_i32(vm))));
return {};
}
LibJS: Reduce number of template literal op codes There is no need to concat empty string literals when building template literals. Now strings will only be concatenated if they need to be. To handle the edge case where the first segment is not a string literal, a new `ToString` op code has been added to ensure the value is a string concatenating more strings. In addition, basic const folding is now supported for template literal constants (templates with no interpolated values), which is commonly used for multi-line string constants.
2026-01-22 17:23:19 -08:00
ThrowCompletionOr<void> ToString::execute_impl(Bytecode::Interpreter& interpreter) const
{
auto& vm = interpreter.vm();
interpreter.set(m_dst, Value { TRY(interpreter.get(m_value).to_primitive_string(vm)) });
return {};
}
LibJS: Fix evaluation order of computed property keys in object literals The spec for PropertyDefinitionEvaluation requires that when evaluating a property definition with a computed key (PropertyDefinition : PropertyName : AssignmentExpression), the PropertyName is fully evaluated (including ToPropertyKey, which calls ToPrimitive) before the value's AssignmentExpression is evaluated. Our bytecode compiler was evaluating the key expression first, then the value expression, and only performing ToPropertyKey later inside PutByValue at runtime. This meant user-observable side effects from ToPrimitive (such as calling Symbol.toPrimitive or toString on the key object) would fire after the value expression had already been evaluated. Fix this by using a new ToPrimitiveWithStringHint instruction that performs ToPrimitive with string hint(!), and emitting it between the key and value evaluations in ObjectExpression codegen. After ToPrimitive, the key is already a primitive, so the subsequent ToPropertyKey inside PutByValue becomes a no-op from the perspective of user-observable side effects. Also update an existing test that was asserting the old (incorrect) evaluation order, and add comprehensive new tests for computed property key evaluation order.
2026-02-08 12:32:38 +01:00
ThrowCompletionOr<void> ToPrimitiveWithStringHint::execute_impl(Bytecode::Interpreter& interpreter) const
{
auto& vm = interpreter.vm();
interpreter.set(m_dst, TRY(interpreter.get(m_value).to_primitive(vm, Value::PreferredType::String)));
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> BitwiseOr::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
{
auto& vm = interpreter.vm();
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto const lhs = interpreter.get(m_lhs);
auto const rhs = interpreter.get(m_rhs);
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
if (lhs.is_int32() && rhs.is_int32()) {
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, Value(lhs.as_i32() | rhs.as_i32()));
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, TRY(bitwise_or(vm, lhs, rhs)));
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> UnsignedRightShift::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
{
auto& vm = interpreter.vm();
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto const lhs = interpreter.get(m_lhs);
auto const rhs = interpreter.get(m_rhs);
LibJS/Bytecode: Increase coverage of left/shift expression fast paths As long as the inputs are Int32, we can convert them to UInt32 in a spec-compliant way with a simple static_cast<u32>. This allows calculations like `-3 >>> 2` to take the fast path as well, which is extremely valuable for stuff like crypto code. While we're doing this, also remove the fast paths from the generic shift functions in Value.cpp, since we only end up there if we *didn't* take the same fast path in the interpreter.
2024-03-04 10:56:21 +01:00
if (lhs.is_int32() && rhs.is_int32()) {
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
auto const shift_count = static_cast<u32>(rhs.as_i32()) % 32;
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, Value(static_cast<u32>(lhs.as_i32()) >> shift_count));
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, TRY(unsigned_right_shift(vm, lhs, rhs)));
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> RightShift::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
{
auto& vm = interpreter.vm();
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto const lhs = interpreter.get(m_lhs);
auto const rhs = interpreter.get(m_rhs);
LibJS/Bytecode: Increase coverage of left/shift expression fast paths As long as the inputs are Int32, we can convert them to UInt32 in a spec-compliant way with a simple static_cast<u32>. This allows calculations like `-3 >>> 2` to take the fast path as well, which is extremely valuable for stuff like crypto code. While we're doing this, also remove the fast paths from the generic shift functions in Value.cpp, since we only end up there if we *didn't* take the same fast path in the interpreter.
2024-03-04 10:56:21 +01:00
if (lhs.is_int32() && rhs.is_int32()) {
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
auto const shift_count = static_cast<u32>(rhs.as_i32()) % 32;
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, Value(lhs.as_i32() >> shift_count));
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, TRY(right_shift(vm, lhs, rhs)));
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> LeftShift::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS/Bytecode: Add fast path for LeftShift with Int32 operands
2024-03-04 10:01:40 +01:00
{
auto& vm = interpreter.vm();
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto const lhs = interpreter.get(m_lhs);
auto const rhs = interpreter.get(m_rhs);
LibJS/Bytecode: Increase coverage of left/shift expression fast paths As long as the inputs are Int32, we can convert them to UInt32 in a spec-compliant way with a simple static_cast<u32>. This allows calculations like `-3 >>> 2` to take the fast path as well, which is extremely valuable for stuff like crypto code. While we're doing this, also remove the fast paths from the generic shift functions in Value.cpp, since we only end up there if we *didn't* take the same fast path in the interpreter.
2024-03-04 10:56:21 +01:00
if (lhs.is_int32() && rhs.is_int32()) {
LibJS/Bytecode: Add fast path for LeftShift with Int32 operands
2024-03-04 10:01:40 +01:00
auto const shift_count = static_cast<u32>(rhs.as_i32()) % 32;
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, Value(lhs.as_i32() << shift_count));
LibJS/Bytecode: Add fast path for LeftShift with Int32 operands
2024-03-04 10:01:40 +01:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, TRY(left_shift(vm, lhs, rhs)));
LibJS/Bytecode: Add fast path for LeftShift with Int32 operands
2024-03-04 10:01:40 +01:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> LessThan::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
{
auto& vm = interpreter.vm();
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto const lhs = interpreter.get(m_lhs);
auto const rhs = interpreter.get(m_rhs);
LibJS: Mark more interpreter fast paths [[likely]] Let's assume arithmetic and comparison operators are mostly being used on numbers.
2025-12-04 22:26:22 +01:00
if (lhs.is_number() && rhs.is_number()) [[likely]] {
LibJS/Bytecode: Add fast paths for compare-and-jump with 2 numbers When comparing two numbers, we can avoid a lot of implicit type conversion nonsense and go straight to comparison, saving time in the most common case.
2024-05-13 09:23:53 +02:00
if (lhs.is_int32() && rhs.is_int32()) {
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, Value(lhs.as_i32() < rhs.as_i32()));
LibJS/Bytecode: Add fast paths for compare-and-jump with 2 numbers When comparing two numbers, we can avoid a lot of implicit type conversion nonsense and go straight to comparison, saving time in the most common case.
2024-05-13 09:23:53 +02:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, Value(lhs.as_double() < rhs.as_double()));
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
return {};
}
LibJS: Avoid roundtrip through Value for comparison bytecode evaluation 1.1x speedup on strictly-equals-object.js
2025-05-08 15:19:35 +12:00
interpreter.set(m_dst, Value { TRY(less_than(vm, lhs, rhs)) });
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> LessThanEquals::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
{
auto& vm = interpreter.vm();
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto const lhs = interpreter.get(m_lhs);
auto const rhs = interpreter.get(m_rhs);
LibJS: Mark more interpreter fast paths [[likely]] Let's assume arithmetic and comparison operators are mostly being used on numbers.
2025-12-04 22:26:22 +01:00
if (lhs.is_number() && rhs.is_number()) [[likely]] {
LibJS/Bytecode: Add fast paths for compare-and-jump with 2 numbers When comparing two numbers, we can avoid a lot of implicit type conversion nonsense and go straight to comparison, saving time in the most common case.
2024-05-13 09:23:53 +02:00
if (lhs.is_int32() && rhs.is_int32()) {
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, Value(lhs.as_i32() <= rhs.as_i32()));
LibJS/Bytecode: Add fast paths for compare-and-jump with 2 numbers When comparing two numbers, we can avoid a lot of implicit type conversion nonsense and go straight to comparison, saving time in the most common case.
2024-05-13 09:23:53 +02:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, Value(lhs.as_double() <= rhs.as_double()));
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
return {};
}
LibJS: Avoid roundtrip through Value for comparison bytecode evaluation 1.1x speedup on strictly-equals-object.js
2025-05-08 15:19:35 +12:00
interpreter.set(m_dst, Value { TRY(less_than_equals(vm, lhs, rhs)) });
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> GreaterThan::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
{
auto& vm = interpreter.vm();
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto const lhs = interpreter.get(m_lhs);
auto const rhs = interpreter.get(m_rhs);
LibJS: Mark more interpreter fast paths [[likely]] Let's assume arithmetic and comparison operators are mostly being used on numbers.
2025-12-04 22:26:22 +01:00
if (lhs.is_number() && rhs.is_number()) [[likely]] {
LibJS/Bytecode: Add fast paths for compare-and-jump with 2 numbers When comparing two numbers, we can avoid a lot of implicit type conversion nonsense and go straight to comparison, saving time in the most common case.
2024-05-13 09:23:53 +02:00
if (lhs.is_int32() && rhs.is_int32()) {
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, Value(lhs.as_i32() > rhs.as_i32()));
LibJS/Bytecode: Add fast paths for compare-and-jump with 2 numbers When comparing two numbers, we can avoid a lot of implicit type conversion nonsense and go straight to comparison, saving time in the most common case.
2024-05-13 09:23:53 +02:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, Value(lhs.as_double() > rhs.as_double()));
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
return {};
}
LibJS: Avoid roundtrip through Value for comparison bytecode evaluation 1.1x speedup on strictly-equals-object.js
2025-05-08 15:19:35 +12:00
interpreter.set(m_dst, Value { TRY(greater_than(vm, lhs, rhs)) });
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> GreaterThanEquals::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
{
auto& vm = interpreter.vm();
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto const lhs = interpreter.get(m_lhs);
auto const rhs = interpreter.get(m_rhs);
LibJS: Mark more interpreter fast paths [[likely]] Let's assume arithmetic and comparison operators are mostly being used on numbers.
2025-12-04 22:26:22 +01:00
if (lhs.is_number() && rhs.is_number()) [[likely]] {
LibJS/Bytecode: Add fast paths for compare-and-jump with 2 numbers When comparing two numbers, we can avoid a lot of implicit type conversion nonsense and go straight to comparison, saving time in the most common case.
2024-05-13 09:23:53 +02:00
if (lhs.is_int32() && rhs.is_int32()) {
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, Value(lhs.as_i32() >= rhs.as_i32()));
LibJS/Bytecode: Add fast paths for compare-and-jump with 2 numbers When comparing two numbers, we can avoid a lot of implicit type conversion nonsense and go straight to comparison, saving time in the most common case.
2024-05-13 09:23:53 +02:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, Value(lhs.as_double() >= rhs.as_double()));
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
return {};
}
LibJS: Avoid roundtrip through Value for comparison bytecode evaluation 1.1x speedup on strictly-equals-object.js
2025-05-08 15:19:35 +12:00
interpreter.set(m_dst, Value { TRY(greater_than_equals(vm, lhs, rhs)) });
LibJS/Bytecode: Add fast paths for many binary expression instructions By handling common cases like Int32 arithmetic directly in the instruction handler, we can avoid the cost of calling the generic helper functions in Value.cpp.
2024-02-20 11:59:46 +01:00
return {};
}
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
LibJS: Mark Not and Typeof as non-throwing instructions
2025-12-04 21:53:10 +01:00
void Typeof::execute_impl(Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
LibJS: Mark Not and Typeof as non-throwing instructions
2025-12-04 21:53:10 +01:00
auto& vm = interpreter.vm();
interpreter.set(dst(), interpreter.get(src()).typeof_(vm));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
LibJS: Mark Not and Typeof as non-throwing instructions
2025-12-04 21:53:10 +01:00
void Not::execute_impl(Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
LibJS: Mark Not and Typeof as non-throwing instructions
2025-12-04 21:53:10 +01:00
interpreter.set(dst(), Value(!interpreter.get(src()).to_boolean()));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
#define JS_DEFINE_COMMON_UNARY_OP(OpTitleCase, op_snake_case) \
ThrowCompletionOr<void> OpTitleCase::execute_impl(Bytecode::Interpreter& interpreter) const \
{ \
auto& vm = interpreter.vm(); \
interpreter.set(dst(), TRY(op_snake_case(vm, interpreter.get(src())))); \
return {}; \
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
JS_ENUMERATE_COMMON_UNARY_OPS(JS_DEFINE_COMMON_UNARY_OP)
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
void NewArray::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
LibJS: Pre-size arrays created by NewArray and NewPrimitiveArray We know the length they're gonna end up with up front since we're instantiating array literals. Pre-sizing them allows us to skip incremental resizing of the property storage.
2026-01-07 22:50:49 +01:00
auto array = MUST(Array::create(interpreter.realm(), m_element_count));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
for (size_t i = 0; i < m_element_count; i++) {
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
array->indexed_properties().put(i, interpreter.get(m_elements[i]), default_attributes);
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(dst(), array);
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
void NewPrimitiveArray::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Instantiate primitive array expressions using a single operation This will not meaningfully affect short array literals, but it does give us a bit of extra perf when evaluating huge array expressions like in Kraken/imaging-darkroom.js
2023-11-17 22:07:23 +02:00
{
LibJS: Pre-size arrays created by NewArray and NewPrimitiveArray We know the length they're gonna end up with up front since we're instantiating array literals. Pre-sizing them allows us to skip incremental resizing of the property storage.
2026-01-07 22:50:49 +01:00
auto array = MUST(Array::create(interpreter.realm(), m_element_count));
LibJS/Bytecode: Make NewPrimitiveArray a variable-length instruction Instead of having a FixedArray with a separate heap allocation, we can just bake the primitive values into the instruction itself.
2024-03-03 12:37:28 +01:00
for (size_t i = 0; i < m_element_count; i++)
array->indexed_properties().put(i, m_elements[i], default_attributes);
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(dst(), array);
LibJS: Instantiate primitive array expressions using a single operation This will not meaningfully affect short array literals, but it does give us a bit of extra perf when evaluating huge array expressions like in Kraken/imaging-darkroom.js
2023-11-17 22:07:23 +02:00
}
LibJS: Follow the spec more closely for tagged template literals This resolves a FIXME in its code generation, particularly for: - Caching the template object - Setting the correct property attributes - Freezing the resulting objects This allows archive.org to load, which uses the Lit library. The Lit library caches these template objects to determine if a template has changed, allowing it to determine to do a full template rerender or only partially update the rendering. Before, we would always cause a full rerender on update because we didn't return the same template object. This caused issues with archive.org's code, I believe particularly with its router library, where we would constantly detach and reattach nodes unexpectedly, ending up with the page content not being attached to the router's custom element.
2026-01-06 19:49:38 +00:00
// 13.2.8.4 GetTemplateObject ( templateLiteral ), https://tc39.es/ecma262/#sec-gettemplateobject
void GetTemplateObject::execute_impl(Bytecode::Interpreter& interpreter) const
{
auto& vm = interpreter.vm();
LibJS: Store cache pointers directly in bytecode instructions Instead of storing a u32 index into a cache vector and looking up the cache at runtime through a chain of dependent loads (load Executable*, load vector data pointer, multiply index, add), store the actual cache pointer as a u64 directly in the instruction stream. A fixup pass (Executable::fixup_cache_pointers()) runs after Executable construction in both the Rust and C++ pipelines, walking the bytecode and replacing each index with the corresponding pointer. The cache pointer type is encoded in Bytecode.def (e.g. PropertyLookupCache*, GlobalVariableCache*) so the fixup switch is auto-generated by the Python Op code generator, making it impossible to forget updating the fixup when adding new cached instructions. This eliminates 3-4 dependent loads on every inline cache access in both the C++ interpreter and the assembly interpreter.
2026-03-07 22:52:25 +01:00
auto& cache = *bit_cast<TemplateObjectCache*>(m_cache);
LibJS: Follow the spec more closely for tagged template literals This resolves a FIXME in its code generation, particularly for: - Caching the template object - Setting the correct property attributes - Freezing the resulting objects This allows archive.org to load, which uses the Lit library. The Lit library caches these template objects to determine if a template has changed, allowing it to determine to do a full template rerender or only partially update the rendering. Before, we would always cause a full rerender on update because we didn't return the same template object. This caused issues with archive.org's code, I believe particularly with its router library, where we would constantly detach and reattach nodes unexpectedly, ending up with the page content not being attached to the router's custom element.
2026-01-06 19:49:38 +00:00
// 1. Let realm be the current Realm Record.
auto& realm = *vm.current_realm();
// 2. Let templateRegistry be realm.[[TemplateMap]].
// 3. For each element e of templateRegistry, do
// a. If e.[[Site]] is the same Parse Node as templateLiteral, then
// i. Return e.[[Array]].
if (cache.cached_template_object) {
interpreter.set(dst(), cache.cached_template_object);
return;
}
// 4. Let rawStrings be the TemplateStrings of templateLiteral with argument true.
// 5. Assert: rawStrings is a List of Strings.
// 6. Let cookedStrings be the TemplateStrings of templateLiteral with argument false.
// NOTE: This has already been done.
// 7. Let count be the number of elements in the List cookedStrings.
// NOTE: m_strings contains [cooked_0, ..., cooked_n, raw_0, ..., raw_n]
// 8. Assert: count ≤ 2**32 - 1.
// NOTE: Done by having count be a u32.
u32 count = m_strings_count / 2;
// 9. Let template be ! ArrayCreate(count).
auto template_object = MUST(Array::create(realm, count));
// 10. Let rawObj be ! ArrayCreate(count).
auto raw_object = MUST(Array::create(realm, count));
// 12. Repeat, while index < count,
for (size_t index = 0; index < count; index++) {
// a. Let prop be ! ToString(𝔽(index)).
// b. Let cookedValue be cookedStrings[index].
auto cooked_value = interpreter.get(m_strings[index]);
// c. Perform ! DefinePropertyOrThrow(template, prop, PropertyDescriptor { [[Value]]: cookedValue, [[Writable]]: false, [[Enumerable]]: true, [[Configurable]]: false }).
template_object->indexed_properties().put(index, cooked_value, Attribute::Enumerable);
// d. Let rawValue be the String value rawStrings[index].
auto raw_value = interpreter.get(m_strings[count + index]);
// e. Perform ! DefinePropertyOrThrow(rawObj, prop, PropertyDescriptor { [[Value]]: rawValue, [[Writable]]: false, [[Enumerable]]: true, [[Configurable]]: false }).
raw_object->indexed_properties().put(index, raw_value, Attribute::Enumerable);
// f. Set index to index + 1.
}
// 13. Perform ! SetIntegrityLevel(rawObj, FROZEN).
MUST(raw_object->set_integrity_level(Object::IntegrityLevel::Frozen));
// 14. Perform ! DefinePropertyOrThrow(template, "raw", PropertyDescriptor { [[Value]]: rawObj, [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false }).
template_object->define_direct_property(vm.names.raw, raw_object, PropertyAttributes {});
// 15. Perform ! SetIntegrityLevel(template, FROZEN).
MUST(template_object->set_integrity_level(Object::IntegrityLevel::Frozen));
// 16. Append the Record { [[Site]]: templateLiteral, [[Array]]: template } to realm.[[TemplateMap]].
cache.cached_template_object = template_object;
// 17. Return template.
interpreter.set(dst(), template_object);
}
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
ThrowCompletionOr<void> NewArrayWithLength::execute_impl(Bytecode::Interpreter& interpreter) const
{
auto length = static_cast<u64>(interpreter.get(m_array_length).as_double());
auto array = TRY(Array::create(interpreter.realm(), length));
interpreter.set(m_dst, array);
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
void AddPrivateName::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Stop using execute_ast_node() for class property evaluation Instead, generate bytecode to execute their AST nodes and save the resulting operands inside the NewClass instruction. Moving property expression evaluation to happen before NewClass execution also moves along creation of new private environment and its population with private members (private members should be visible during property evaluation). Before: - NewClass After: - CreatePrivateEnvironment - AddPrivateName - ... - AddPrivateName - NewClass - LeavePrivateEnvironment
2024-05-11 22:54:41 +00:00
{
LibJS: Give Interpreter a direct pointer to the identifier table This gets rid of a lot of pointer chasing from interpreter to executable to identifier table to the actual identifier. 1.05x speed-up on Kraken/ai-astar.js
2025-10-07 16:47:41 +02:00
auto const& name = interpreter.get_identifier(m_name);
LibJS: Stop using execute_ast_node() for class property evaluation Instead, generate bytecode to execute their AST nodes and save the resulting operands inside the NewClass instruction. Moving property expression evaluation to happen before NewClass execution also moves along creation of new private environment and its population with private members (private members should be visible during property evaluation). Before: - NewClass After: - CreatePrivateEnvironment - AddPrivateName - ... - AddPrivateName - NewClass - LeavePrivateEnvironment
2024-05-11 22:54:41 +00:00
interpreter.vm().running_execution_context().private_environment->add_private_name(name);
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> ArrayAppend::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
return append(interpreter.vm(), interpreter.get(dst()), interpreter.get(src()), m_is_spread);
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> ImportCall::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
auto& vm = interpreter.vm();
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto specifier = interpreter.get(m_specifier);
auto options_value = interpreter.get(m_options);
interpreter.set(dst(), TRY(perform_import_call(vm, specifier, options_value)));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> IteratorToArray::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
LibJS: Avoid `IteratorRecord` GC-allocation in `GetIterator` instruction With this change, `GetIterator` no longer GC-allocates an `IteratorRecord`. Instead, it stores the iterator record fields in bytecode registers. This avoids per-iteration allocations in patterns like: `for (let [x] of array) {}`. `IteratorRecord` now inherits from `IteratorRecordImpl`, which holds the iteration state. This allows the existing iteration helpers (`iterator_next()`, `iterator_step()`, etc.) operate on both the GC-allocated and the register-backed forms. Microbenchmarks: 1.1x array-destructuring-assignment-rest.js 1.226x array-destructuring-assignment.js
2025-10-27 19:46:54 +01:00
auto& vm = interpreter.vm();
auto& iterator_object = interpreter.get(m_iterator_object).as_object();
auto iterator_next_method = interpreter.get(m_iterator_next_method);
auto iterator_done_property = interpreter.get(m_iterator_done_property).as_bool();
IteratorRecordImpl iterator_record { .done = iterator_done_property, .iterator = iterator_object, .next_method = iterator_next_method };
auto array = MUST(Array::create(*vm.current_realm(), 0));
size_t index = 0;
while (true) {
auto value = TRY(iterator_step_value(vm, iterator_record));
if (!value.has_value())
break;
MUST(array->create_data_property_or_throw(index, value.release_value()));
index++;
}
interpreter.set(dst(), array);
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
void NewObject::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto& vm = interpreter.vm();
auto& realm = *vm.current_realm();
LibJS: Add shape caching for object literal instantiation When a function creates object literals with simple property names, we now cache the resulting shape after the first instantiation. On subsequent calls, we create the object with the cached shape directly and write property values at their known offsets. This avoids repeated shape transitions and property offset lookups for a common JavaScript pattern. The optimization uses two new bytecode instructions: - CacheObjectShape: Captures the final shape after object construction - InitObjectLiteralProperty: Writes properties using cached offsets Only "simple" object literals are optimized (string literal keys with simple value expressions). Complex cases like computed properties, getters/setters, and spread elements use the existing slow path. 3.4x speedup on a microbenchmark that repeatedly instantiates an object literal with 26 properties. Small progressions on various benchmarks.
2026-01-09 18:55:00 +01:00
LibJS: Store cache pointers directly in bytecode instructions Instead of storing a u32 index into a cache vector and looking up the cache at runtime through a chain of dependent loads (load Executable*, load vector data pointer, multiply index, add), store the actual cache pointer as a u64 directly in the instruction stream. A fixup pass (Executable::fixup_cache_pointers()) runs after Executable construction in both the Rust and C++ pipelines, walking the bytecode and replacing each index with the corresponding pointer. The cache pointer type is encoded in Bytecode.def (e.g. PropertyLookupCache*, GlobalVariableCache*) so the fixup switch is auto-generated by the Python Op code generator, making it impossible to forget updating the fixup when adding new cached instructions. This eliminates 3-4 dependent loads on every inline cache access in both the C++ interpreter and the assembly interpreter.
2026-03-07 22:52:25 +01:00
if (m_cache) {
auto& cache = *bit_cast<ObjectShapeCache*>(m_cache);
LibJS: Add shape caching for object literal instantiation When a function creates object literals with simple property names, we now cache the resulting shape after the first instantiation. On subsequent calls, we create the object with the cached shape directly and write property values at their known offsets. This avoids repeated shape transitions and property offset lookups for a common JavaScript pattern. The optimization uses two new bytecode instructions: - CacheObjectShape: Captures the final shape after object construction - InitObjectLiteralProperty: Writes properties using cached offsets Only "simple" object literals are optimized (string literal keys with simple value expressions). Complex cases like computed properties, getters/setters, and spread elements use the existing slow path. 3.4x speedup on a microbenchmark that repeatedly instantiates an object literal with 26 properties. Small progressions on various benchmarks.
2026-01-09 18:55:00 +01:00
auto cached_shape = cache.shape.ptr();
if (cached_shape) {
interpreter.set(dst(), Object::create_with_premade_shape(*cached_shape));
return;
}
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(dst(), Object::create(realm, realm.intrinsics().object_prototype()));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
void NewObjectWithNoPrototype::execute_impl(Bytecode::Interpreter& interpreter) const
{
auto& vm = interpreter.vm();
auto& realm = *vm.current_realm();
interpreter.set(dst(), Object::create(realm, nullptr));
}
LibJS: Add shape caching for object literal instantiation When a function creates object literals with simple property names, we now cache the resulting shape after the first instantiation. On subsequent calls, we create the object with the cached shape directly and write property values at their known offsets. This avoids repeated shape transitions and property offset lookups for a common JavaScript pattern. The optimization uses two new bytecode instructions: - CacheObjectShape: Captures the final shape after object construction - InitObjectLiteralProperty: Writes properties using cached offsets Only "simple" object literals are optimized (string literal keys with simple value expressions). Complex cases like computed properties, getters/setters, and spread elements use the existing slow path. 3.4x speedup on a microbenchmark that repeatedly instantiates an object literal with 26 properties. Small progressions on various benchmarks.
2026-01-09 18:55:00 +01:00
void CacheObjectShape::execute_impl(Bytecode::Interpreter& interpreter) const
{
LibJS: Store cache pointers directly in bytecode instructions Instead of storing a u32 index into a cache vector and looking up the cache at runtime through a chain of dependent loads (load Executable*, load vector data pointer, multiply index, add), store the actual cache pointer as a u64 directly in the instruction stream. A fixup pass (Executable::fixup_cache_pointers()) runs after Executable construction in both the Rust and C++ pipelines, walking the bytecode and replacing each index with the corresponding pointer. The cache pointer type is encoded in Bytecode.def (e.g. PropertyLookupCache*, GlobalVariableCache*) so the fixup switch is auto-generated by the Python Op code generator, making it impossible to forget updating the fixup when adding new cached instructions. This eliminates 3-4 dependent loads on every inline cache access in both the C++ interpreter and the assembly interpreter.
2026-03-07 22:52:25 +01:00
auto& cache = *bit_cast<ObjectShapeCache*>(m_cache);
LibJS: Add shape caching for object literal instantiation When a function creates object literals with simple property names, we now cache the resulting shape after the first instantiation. On subsequent calls, we create the object with the cached shape directly and write property values at their known offsets. This avoids repeated shape transitions and property offset lookups for a common JavaScript pattern. The optimization uses two new bytecode instructions: - CacheObjectShape: Captures the final shape after object construction - InitObjectLiteralProperty: Writes properties using cached offsets Only "simple" object literals are optimized (string literal keys with simple value expressions). Complex cases like computed properties, getters/setters, and spread elements use the existing slow path. 3.4x speedup on a microbenchmark that repeatedly instantiates an object literal with 26 properties. Small progressions on various benchmarks.
2026-01-09 18:55:00 +01:00
if (!cache.shape) {
auto& object = interpreter.get(m_object).as_object();
cache.shape = &object.shape();
}
}
COLD static void init_object_literal_property_slow(Object& object, PropertyKey const& property_key, Value value, ObjectShapeCache& cache, u32 property_slot)
{
object.define_direct_property(property_key, value, JS::Attribute::Enumerable | JS::Attribute::Writable | JS::Attribute::Configurable);
// Cache the property offset for future fast-path use
// Note: lookup may fail if the shape is in dictionary mode or for other edge cases.
// We only cache if we're not in dictionary mode and the lookup succeeds.
if (!object.shape().is_dictionary()) {
auto metadata = object.shape().lookup(property_key);
if (metadata.has_value()) {
if (property_slot >= cache.property_offsets.size())
cache.property_offsets.resize(property_slot + 1);
cache.property_offsets[property_slot] = metadata->offset;
}
}
}
void InitObjectLiteralProperty::execute_impl(Bytecode::Interpreter& interpreter) const
{
auto& object = interpreter.get(m_object).as_object();
auto value = interpreter.get(m_src);
auto& cache = interpreter.current_executable().object_shape_caches[m_shape_cache_index];
// Fast path: if we have a cached shape and it matches, write directly to the cached offset
auto cached_shape = cache.shape.ptr();
if (cached_shape && &object.shape() == cached_shape && m_property_slot < cache.property_offsets.size()) {
object.put_direct(cache.property_offsets[m_property_slot], value);
return;
}
auto const& property_key = interpreter.current_executable().get_property_key(m_property);
init_object_literal_property_slow(object, property_key, value, cache, m_property_slot);
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
void NewRegExp::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(dst(),
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
new_regexp(
interpreter.vm(),
interpreter.current_executable().regex_table->get(m_regex_index),
LibJS+LibWeb: Port interned bytecode strings to UTF-16 This was almost a no-op, except we intern JS exception messages. So the bulk of this patch is porting exception messages to UTF-16.
2025-08-07 19:31:52 -04:00
interpreter.current_executable().get_string(m_source_index),
interpreter.current_executable().get_string(m_flags_index)));
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
}
LibJS: Throw ReferenceError for delete super[...] at codegen time delete super.x and delete super[expr] always throw a ReferenceError per spec. Instead of deferring this to runtime via DeleteByIdWithThis and DeleteByValueWithThis instructions, emit the throw directly during bytecode generation. Remove the now-unused DeleteByIdWithThis and DeleteByValueWithThis instructions, and add a NewReferenceError instruction.
2026-02-11 13:14:52 +01:00
COLD void NewReferenceError::execute_impl(Interpreter& interpreter) const
{
auto& vm = interpreter.vm();
auto& realm = *vm.current_realm();
interpreter.set(dst(), ReferenceError::create(realm, interpreter.current_executable().get_string(m_error_string)));
}
LibJS: Mark NewTypeError instruction COLD Missed this one when marking all the various throwing paths in the interpreter cold/unlikely.
2025-12-11 11:35:08 -06:00
COLD void NewTypeError::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
{
auto& vm = interpreter.vm();
auto& realm = *vm.current_realm();
interpreter.set(dst(), TypeError::create(realm, interpreter.current_executable().get_string(m_error_string)));
}
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> CopyObjectExcludingProperties::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
auto& vm = interpreter.vm();
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto& realm = *vm.current_realm();
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto from_object = interpreter.get(m_from_object);
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
auto to_object = Object::create(realm, realm.intrinsics().object_prototype());
HashTable<PropertyKey> excluded_names;
for (size_t i = 0; i < m_excluded_names_count; ++i) {
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
excluded_names.set(TRY(interpreter.get(m_excluded_names[i]).to_property_key(vm)));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
TRY(to_object->copy_data_properties(vm, from_object, excluded_names));
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(dst(), to_object);
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return {};
}
Revert "LibJS: Remove unnecessary ConcatString bytecode instruction" This reverts commit 420187ba7c3afbd9792a3042a65978666c2de7f7. Caused 41 regressions in test262.
2025-12-10 09:17:05 -06:00
ThrowCompletionOr<void> ConcatString::execute_impl(Bytecode::Interpreter& interpreter) const
{
auto& vm = interpreter.vm();
auto string = TRY(interpreter.get(src()).to_primitive_string(vm));
interpreter.set(dst(), PrimitiveString::create(vm, interpreter.get(dst()).as_string(), string));
return {};
}
LibJS: Optimize reading known-to-be-initialized `var` bindings `var` bindings are never in the temporal dead zone (TDZ), and so we know accessing them will not throw. We now take advantage of this by having a specialized environment binding value getter that doesn't check for exceptional cases. 1.08x speedup on JetStream.
2025-05-04 01:41:49 +02:00
enum class BindingIsKnownToBeInitialized {
No,
Yes,
};
template<BindingIsKnownToBeInitialized binding_is_known_to_be_initialized>
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
static ThrowCompletionOr<void> get_binding(Interpreter& interpreter, Operand dst, IdentifierTableIndex identifier, Strict strict, EnvironmentCoordinate& cache)
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
LibJS: Inline more of cached environment variable access in interpreter And stop passing VM strictness to direct access, since it doesn't care about strictness anyway.
2024-05-11 17:22:59 +02:00
auto& vm = interpreter.vm();
LibJS: Use [[likely]] annotations for cached environment lookups These will generally be cached the vast majority of the time except on first encounter, and sprinkling [[likely]] gives us a nice boost. 1.10x speed-up on this micro-benchmark: (() => { var a = 3; for (let i = 0; i < 100_000_000; ++i) { a; } eval(""); })();
2025-10-07 16:37:22 +02:00
if (cache.is_valid()) [[likely]] {
LibJS/Bytecode: Cache the running execution context in interpreter
2024-05-11 18:16:27 +02:00
auto const* environment = interpreter.running_execution_context().lexical_environment.ptr();
LibJS: Limit eval() deoptimization to the containing function scope Previously, when direct eval() was called, we would mark the entire environment chain as "permanently screwed by eval", disabling variable access caching all the way up to the global scope. This was overly conservative. According to the ECMAScript specification, a sloppy direct eval() can only inject var declarations into its containing function's variable environment - it cannot inject variables into parent function scopes. This patch makes two changes: 1. Stop propagating the "screwed by eval" flag at function boundaries. When set_permanently_screwed_by_eval() hits a FunctionEnvironment or GlobalEnvironment, it no longer continues to outer environments. 2. Check each environment during cache lookup traversal. If any environment in the path is marked as screwed, we bail to the slow path. This catches the case where we're inside a function with eval and have a cached coordinate pointing to an outer scope. The second change is necessary because eval can create local variables that shadow outer bindings. When looking up a variable from inside a function that called eval, we can't trust cached coordinates that point to outer scopes, since eval may have created a closer binding. This improves performance for code with nested functions where an inner function uses eval but parent functions perform many variable accesses. The parent functions can now use cached environment coordinates. All 29 new tests verify behavior matches V8.
2026-01-26 20:40:05 +01:00
for (size_t i = 0; i < cache.hops; ++i) {
if (environment->is_permanently_screwed_by_eval()) [[unlikely]]
goto slow_path;
LibJS: Inline more of cached environment variable access in interpreter And stop passing VM strictness to direct access, since it doesn't care about strictness anyway.
2024-05-11 17:22:59 +02:00
environment = environment->outer_environment();
LibJS: Limit eval() deoptimization to the containing function scope Previously, when direct eval() was called, we would mark the entire environment chain as "permanently screwed by eval", disabling variable access caching all the way up to the global scope. This was overly conservative. According to the ECMAScript specification, a sloppy direct eval() can only inject var declarations into its containing function's variable environment - it cannot inject variables into parent function scopes. This patch makes two changes: 1. Stop propagating the "screwed by eval" flag at function boundaries. When set_permanently_screwed_by_eval() hits a FunctionEnvironment or GlobalEnvironment, it no longer continues to outer environments. 2. Check each environment during cache lookup traversal. If any environment in the path is marked as screwed, we bail to the slow path. This catches the case where we're inside a function with eval and have a cached coordinate pointing to an outer scope. The second change is necessary because eval can create local variables that shadow outer bindings. When looking up a variable from inside a function that called eval, we can't trust cached coordinates that point to outer scopes, since eval may have created a closer binding. This improves performance for code with nested functions where an inner function uses eval but parent functions perform many variable accesses. The parent functions can now use cached environment coordinates. All 29 new tests verify behavior matches V8.
2026-01-26 20:40:05 +01:00
}
LibJS: Use [[likely]] annotations for cached environment lookups These will generally be cached the vast majority of the time except on first encounter, and sprinkling [[likely]] gives us a nice boost. 1.10x speed-up on this micro-benchmark: (() => { var a = 3; for (let i = 0; i < 100_000_000; ++i) { a; } eval(""); })();
2025-10-07 16:37:22 +02:00
if (!environment->is_permanently_screwed_by_eval()) [[likely]] {
LibJS: Optimize reading known-to-be-initialized `var` bindings `var` bindings are never in the temporal dead zone (TDZ), and so we know accessing them will not throw. We now take advantage of this by having a specialized environment binding value getter that doesn't check for exceptional cases. 1.08x speedup on JetStream.
2025-05-04 01:41:49 +02:00
Value value;
if constexpr (binding_is_known_to_be_initialized == BindingIsKnownToBeInitialized::No) {
value = TRY(static_cast<DeclarativeEnvironment const&>(*environment).get_binding_value_direct(vm, cache.index));
} else {
value = static_cast<DeclarativeEnvironment const&>(*environment).get_initialized_binding_value_direct(cache.index);
}
interpreter.set(dst, value);
LibJS: Inline more of cached environment variable access in interpreter And stop passing VM strictness to direct access, since it doesn't care about strictness anyway.
2024-05-11 17:22:59 +02:00
return {};
}
LibJS: Limit eval() deoptimization to the containing function scope Previously, when direct eval() was called, we would mark the entire environment chain as "permanently screwed by eval", disabling variable access caching all the way up to the global scope. This was overly conservative. According to the ECMAScript specification, a sloppy direct eval() can only inject var declarations into its containing function's variable environment - it cannot inject variables into parent function scopes. This patch makes two changes: 1. Stop propagating the "screwed by eval" flag at function boundaries. When set_permanently_screwed_by_eval() hits a FunctionEnvironment or GlobalEnvironment, it no longer continues to outer environments. 2. Check each environment during cache lookup traversal. If any environment in the path is marked as screwed, we bail to the slow path. This catches the case where we're inside a function with eval and have a cached coordinate pointing to an outer scope. The second change is necessary because eval can create local variables that shadow outer bindings. When looking up a variable from inside a function that called eval, we can't trust cached coordinates that point to outer scopes, since eval may have created a closer binding. This improves performance for code with nested functions where an inner function uses eval but parent functions perform many variable accesses. The parent functions can now use cached environment coordinates. All 29 new tests verify behavior matches V8.
2026-01-26 20:40:05 +01:00
slow_path:
LibJS: Optimize reading known-to-be-initialized `var` bindings `var` bindings are never in the temporal dead zone (TDZ), and so we know accessing them will not throw. We now take advantage of this by having a specialized environment binding value getter that doesn't check for exceptional cases. 1.08x speedup on JetStream.
2025-05-04 01:41:49 +02:00
cache = {};
LibJS: Inline more of cached environment variable access in interpreter And stop passing VM strictness to direct access, since it doesn't care about strictness anyway.
2024-05-11 17:22:59 +02:00
}
LibJS: Use [[likely]] annotations for cached environment lookups These will generally be cached the vast majority of the time except on first encounter, and sprinkling [[likely]] gives us a nice boost. 1.10x speed-up on this micro-benchmark: (() => { var a = 3; for (let i = 0; i < 100_000_000; ++i) { a; } eval(""); })();
2025-10-07 16:37:22 +02:00
auto& executable = interpreter.current_executable();
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
auto reference = TRY(vm.resolve_binding(executable.get_identifier(identifier), strict));
LibJS: Inline more of cached environment variable access in interpreter And stop passing VM strictness to direct access, since it doesn't care about strictness anyway.
2024-05-11 17:22:59 +02:00
if (reference.environment_coordinate().has_value())
LibJS: Optimize reading known-to-be-initialized `var` bindings `var` bindings are never in the temporal dead zone (TDZ), and so we know accessing them will not throw. We now take advantage of this by having a specialized environment binding value getter that doesn't check for exceptional cases. 1.08x speedup on JetStream.
2025-05-04 01:41:49 +02:00
cache = reference.environment_coordinate().value();
LibJS: Limit eval() deoptimization to the containing function scope Previously, when direct eval() was called, we would mark the entire environment chain as "permanently screwed by eval", disabling variable access caching all the way up to the global scope. This was overly conservative. According to the ECMAScript specification, a sloppy direct eval() can only inject var declarations into its containing function's variable environment - it cannot inject variables into parent function scopes. This patch makes two changes: 1. Stop propagating the "screwed by eval" flag at function boundaries. When set_permanently_screwed_by_eval() hits a FunctionEnvironment or GlobalEnvironment, it no longer continues to outer environments. 2. Check each environment during cache lookup traversal. If any environment in the path is marked as screwed, we bail to the slow path. This catches the case where we're inside a function with eval and have a cached coordinate pointing to an outer scope. The second change is necessary because eval can create local variables that shadow outer bindings. When looking up a variable from inside a function that called eval, we can't trust cached coordinates that point to outer scopes, since eval may have created a closer binding. This improves performance for code with nested functions where an inner function uses eval but parent functions perform many variable accesses. The parent functions can now use cached environment coordinates. All 29 new tests verify behavior matches V8.
2026-01-26 20:40:05 +01:00
LibJS: Optimize reading known-to-be-initialized `var` bindings `var` bindings are never in the temporal dead zone (TDZ), and so we know accessing them will not throw. We now take advantage of this by having a specialized environment binding value getter that doesn't check for exceptional cases. 1.08x speedup on JetStream.
2025-05-04 01:41:49 +02:00
interpreter.set(dst, TRY(reference.get_value(vm)));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return {};
}
LibJS: Optimize reading known-to-be-initialized `var` bindings `var` bindings are never in the temporal dead zone (TDZ), and so we know accessing them will not throw. We now take advantage of this by having a specialized environment binding value getter that doesn't check for exceptional cases. 1.08x speedup on JetStream.
2025-05-04 01:41:49 +02:00
ThrowCompletionOr<void> GetBinding::execute_impl(Bytecode::Interpreter& interpreter) const
{
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
return get_binding<BindingIsKnownToBeInitialized::No>(interpreter, m_dst, m_identifier, strict(), m_cache);
LibJS: Optimize reading known-to-be-initialized `var` bindings `var` bindings are never in the temporal dead zone (TDZ), and so we know accessing them will not throw. We now take advantage of this by having a specialized environment binding value getter that doesn't check for exceptional cases. 1.08x speedup on JetStream.
2025-05-04 01:41:49 +02:00
}
ThrowCompletionOr<void> GetInitializedBinding::execute_impl(Bytecode::Interpreter& interpreter) const
{
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
return get_binding<BindingIsKnownToBeInitialized::Yes>(interpreter, m_dst, m_identifier, strict(), m_cache);
LibJS: Optimize reading known-to-be-initialized `var` bindings `var` bindings are never in the temporal dead zone (TDZ), and so we know accessing them will not throw. We now take advantage of this by having a specialized environment binding value getter that doesn't check for exceptional cases. 1.08x speedup on JetStream.
2025-05-04 01:41:49 +02:00
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> GetCalleeAndThisFromEnvironment::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
LibJS/JIT: Resolve the GetCalleeAndThisFromEnvironment cache at JIT time
2023-11-10 13:00:36 +01:00
auto callee_and_this = TRY(get_callee_and_this_from_environment(
interpreter,
LibJS: Give Interpreter a direct pointer to the identifier table This gets rid of a lot of pointer chasing from interpreter to executable to identifier table to the actual identifier. 1.05x speed-up on Kraken/ai-astar.js
2025-10-07 16:47:41 +02:00
interpreter.get_identifier(m_identifier),
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
strict(),
LibJS/Bytecode: Move environment variable caches into instructions These were out-of-line because we had some ideas about marking instruction streams PROT_READ only, but that seems pretty arbitrary and there's a lot of performance to be gained by putting these inline.
2024-05-11 18:28:03 +02:00
m_cache));
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_callee, callee_and_this.callee);
interpreter.set(m_this_value, callee_and_this.this_value);
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> GetGlobal::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
LibJS: Store cache pointers directly in bytecode instructions Instead of storing a u32 index into a cache vector and looking up the cache at runtime through a chain of dependent loads (load Executable*, load vector data pointer, multiply index, add), store the actual cache pointer as a u64 directly in the instruction stream. A fixup pass (Executable::fixup_cache_pointers()) runs after Executable construction in both the Rust and C++ pipelines, walking the bytecode and replacing each index with the corresponding pointer. The cache pointer type is encoded in Bytecode.def (e.g. PropertyLookupCache*, GlobalVariableCache*) so the fixup switch is auto-generated by the Python Op code generator, making it impossible to forget updating the fixup when adding new cached instructions. This eliminates 3-4 dependent loads on every inline cache access in both the C++ interpreter and the assembly interpreter.
2026-03-07 22:52:25 +01:00
interpreter.set(dst(), TRY(get_global(interpreter, m_identifier, strict(), *bit_cast<GlobalVariableCache*>(m_cache))));
LibJS/JIT: Compile the GetGlobal bytecode instruction
2023-10-20 12:56:12 +02:00
return {};
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
LibJS: Add SetGlobal bytecode instruction for cached global writes Before this change, setting a global would end up as SetLexicalBinding. That instruction always failed to cache the access if the global was a property of the global object. 1.14x speedup on Octane/earley-boyer.js 2.04x speedup on MicroBench/for-of.js Note that MicroBench/for-of.js was more of a "set global" benchmark before this. After this change, it's actually a for..of benchmark. :^)
2025-05-01 23:58:38 +02:00
ThrowCompletionOr<void> SetGlobal::execute_impl(Bytecode::Interpreter& interpreter) const
{
auto& vm = interpreter.vm();
auto& binding_object = interpreter.global_object();
auto& declarative_record = interpreter.global_declarative_environment();
LibJS: Store cache pointers directly in bytecode instructions Instead of storing a u32 index into a cache vector and looking up the cache at runtime through a chain of dependent loads (load Executable*, load vector data pointer, multiply index, add), store the actual cache pointer as a u64 directly in the instruction stream. A fixup pass (Executable::fixup_cache_pointers()) runs after Executable construction in both the Rust and C++ pipelines, walking the bytecode and replacing each index with the corresponding pointer. The cache pointer type is encoded in Bytecode.def (e.g. PropertyLookupCache*, GlobalVariableCache*) so the fixup switch is auto-generated by the Python Op code generator, making it impossible to forget updating the fixup when adding new cached instructions. This eliminates 3-4 dependent loads on every inline cache access in both the C++ interpreter and the assembly interpreter.
2026-03-07 22:52:25 +01:00
auto& cache = *bit_cast<GlobalVariableCache*>(m_cache);
LibJS: Add SetGlobal bytecode instruction for cached global writes Before this change, setting a global would end up as SetLexicalBinding. That instruction always failed to cache the access if the global was a property of the global object. 1.14x speedup on Octane/earley-boyer.js 2.04x speedup on MicroBench/for-of.js Note that MicroBench/for-of.js was more of a "set global" benchmark before this. After this change, it's actually a for..of benchmark. :^)
2025-05-01 23:58:38 +02:00
auto& shape = binding_object.shape();
auto src = interpreter.get(m_src);
if (cache.environment_serial_number == declarative_record.environment_serial_number()) {
// OPTIMIZATION: For global var bindings, if the shape of the global object hasn't changed,
// we can use the cached property offset.
LibJS: Shrink PropertyLookupCache::Entry size by tweaking layout Reorder members and use u32 instead of Optional<u32> for things that didn't actually need the "empty" state other than for assertions. Reduces memory usage on my x.com home feed by 9.9 MiB.
2025-12-20 16:16:16 -06:00
if (&shape == cache.entries[0].shape && (!shape.is_dictionary() || shape.dictionary_generation() == cache.entries[0].shape_dictionary_generation)) {
auto value = binding_object.get_direct(cache.entries[0].property_offset);
LibJS: Add SetGlobal bytecode instruction for cached global writes Before this change, setting a global would end up as SetLexicalBinding. That instruction always failed to cache the access if the global was a property of the global object. 1.14x speedup on Octane/earley-boyer.js 2.04x speedup on MicroBench/for-of.js Note that MicroBench/for-of.js was more of a "set global" benchmark before this. After this change, it's actually a for..of benchmark. :^)
2025-05-01 23:58:38 +02:00
if (value.is_accessor())
LibJS: Cache PutById to setters in the prototype chain This is *extremely* common on the web, but barely shows up at all in JavaScript benchmarks. A typical example is setting Element.innerHTML on a HTMLDivElement. HTMLDivElement doesn't have innerHTML, so it has to travel up the prototype chain until it finds it. Before this change, we didn't cache this at all, so we had to travel the prototype chain every time a setter like this was used. We now use the same mechanism we already had for GetBydId and cache PutById setter accesses in the prototype chain as well. 1.74x speedup on MicroBench/setter-in-prototype-chain.js
2025-05-04 16:00:13 +02:00
TRY(call(vm, value.as_accessor().setter(), &binding_object, src));
LibJS: Add SetGlobal bytecode instruction for cached global writes Before this change, setting a global would end up as SetLexicalBinding. That instruction always failed to cache the access if the global was a property of the global object. 1.14x speedup on Octane/earley-boyer.js 2.04x speedup on MicroBench/for-of.js Note that MicroBench/for-of.js was more of a "set global" benchmark before this. After this change, it's actually a for..of benchmark. :^)
2025-05-01 23:58:38 +02:00
else
LibJS: Shrink PropertyLookupCache::Entry size by tweaking layout Reorder members and use u32 instead of Optional<u32> for things that didn't actually need the "empty" state other than for assertions. Reduces memory usage on my x.com home feed by 9.9 MiB.
2025-12-20 16:16:16 -06:00
binding_object.put_direct(cache.entries[0].property_offset, src);
LibJS: Add SetGlobal bytecode instruction for cached global writes Before this change, setting a global would end up as SetLexicalBinding. That instruction always failed to cache the access if the global was a property of the global object. 1.14x speedup on Octane/earley-boyer.js 2.04x speedup on MicroBench/for-of.js Note that MicroBench/for-of.js was more of a "set global" benchmark before this. After this change, it's actually a for..of benchmark. :^)
2025-05-01 23:58:38 +02:00
return {};
}
// OPTIMIZATION: For global lexical bindings, if the global declarative environment hasn't changed,
// we can use the cached environment binding index.
if (cache.has_environment_binding_index) {
if (cache.in_module_environment) {
auto module = vm.running_execution_context().script_or_module.get_pointer<GC::Ref<Module>>();
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
TRY((*module)->environment()->set_mutable_binding_direct(vm, cache.environment_binding_index, src, strict() == Strict::Yes));
LibJS: Add SetGlobal bytecode instruction for cached global writes Before this change, setting a global would end up as SetLexicalBinding. That instruction always failed to cache the access if the global was a property of the global object. 1.14x speedup on Octane/earley-boyer.js 2.04x speedup on MicroBench/for-of.js Note that MicroBench/for-of.js was more of a "set global" benchmark before this. After this change, it's actually a for..of benchmark. :^)
2025-05-01 23:58:38 +02:00
} else {
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
TRY(declarative_record.set_mutable_binding_direct(vm, cache.environment_binding_index, src, strict() == Strict::Yes));
LibJS: Add SetGlobal bytecode instruction for cached global writes Before this change, setting a global would end up as SetLexicalBinding. That instruction always failed to cache the access if the global was a property of the global object. 1.14x speedup on Octane/earley-boyer.js 2.04x speedup on MicroBench/for-of.js Note that MicroBench/for-of.js was more of a "set global" benchmark before this. After this change, it's actually a for..of benchmark. :^)
2025-05-01 23:58:38 +02:00
}
return {};
}
}
cache.environment_serial_number = declarative_record.environment_serial_number();
LibJS: Give Interpreter a direct pointer to the identifier table This gets rid of a lot of pointer chasing from interpreter to executable to identifier table to the actual identifier. 1.05x speed-up on Kraken/ai-astar.js
2025-10-07 16:47:41 +02:00
auto& identifier = interpreter.get_identifier(m_identifier);
LibJS: Add SetGlobal bytecode instruction for cached global writes Before this change, setting a global would end up as SetLexicalBinding. That instruction always failed to cache the access if the global was a property of the global object. 1.14x speedup on Octane/earley-boyer.js 2.04x speedup on MicroBench/for-of.js Note that MicroBench/for-of.js was more of a "set global" benchmark before this. After this change, it's actually a for..of benchmark. :^)
2025-05-01 23:58:38 +02:00
if (auto* module = vm.running_execution_context().script_or_module.get_pointer<GC::Ref<Module>>()) {
// NOTE: GetGlobal is used to access variables stored in the module environment and global environment.
// The module environment is checked first since it precedes the global environment in the environment chain.
auto& module_environment = *(*module)->environment();
Optional<size_t> index;
if (TRY(module_environment.has_binding(identifier, &index))) {
if (index.has_value()) {
cache.environment_binding_index = static_cast<u32>(index.value());
cache.has_environment_binding_index = true;
cache.in_module_environment = true;
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
return TRY(module_environment.set_mutable_binding_direct(vm, index.value(), src, strict() == Strict::Yes));
LibJS: Add SetGlobal bytecode instruction for cached global writes Before this change, setting a global would end up as SetLexicalBinding. That instruction always failed to cache the access if the global was a property of the global object. 1.14x speedup on Octane/earley-boyer.js 2.04x speedup on MicroBench/for-of.js Note that MicroBench/for-of.js was more of a "set global" benchmark before this. After this change, it's actually a for..of benchmark. :^)
2025-05-01 23:58:38 +02:00
}
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
return TRY(module_environment.set_mutable_binding(vm, identifier, src, strict() == Strict::Yes));
LibJS: Add SetGlobal bytecode instruction for cached global writes Before this change, setting a global would end up as SetLexicalBinding. That instruction always failed to cache the access if the global was a property of the global object. 1.14x speedup on Octane/earley-boyer.js 2.04x speedup on MicroBench/for-of.js Note that MicroBench/for-of.js was more of a "set global" benchmark before this. After this change, it's actually a for..of benchmark. :^)
2025-05-01 23:58:38 +02:00
}
}
Optional<size_t> offset;
if (TRY(declarative_record.has_binding(identifier, &offset))) {
cache.environment_binding_index = static_cast<u32>(offset.value());
cache.has_environment_binding_index = true;
cache.in_module_environment = false;
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
TRY(declarative_record.set_mutable_binding(vm, identifier, src, strict() == Strict::Yes));
LibJS: Add SetGlobal bytecode instruction for cached global writes Before this change, setting a global would end up as SetLexicalBinding. That instruction always failed to cache the access if the global was a property of the global object. 1.14x speedup on Octane/earley-boyer.js 2.04x speedup on MicroBench/for-of.js Note that MicroBench/for-of.js was more of a "set global" benchmark before this. After this change, it's actually a for..of benchmark. :^)
2025-05-01 23:58:38 +02:00
return {};
}
if (TRY(binding_object.has_property(identifier))) {
LibJS: Add inline caching for adding new own properties to objects We already had IC support in PutById for the following cases: - Changing an existing own property - Calling a setter located in the prototype chain This was enough to speed up code where structurally identical objects (same shape) are processed in a loop: ```js const arr = [{ a: 1 }, { a: 2 }, { a: 3 }]; for (let obj of arr) { obj.a += 1; } ``` However, creating structurally identical objects in a loop was still slow: ```js for (let i = 0; i < 10_000_000; i++) { const o = {}; o.a = 1; o.b = 2; o.c = 3; } ``` This change addresses that by adding a new IC type that caches both the source and target shapes, allowing property additions to be fast-pathed by directly jumping to the shape that already includes the new property.
2025-09-15 17:23:39 +02:00
CacheableSetPropertyMetadata cacheable_metadata;
LibJS: Add SetGlobal bytecode instruction for cached global writes Before this change, setting a global would end up as SetLexicalBinding. That instruction always failed to cache the access if the global was a property of the global object. 1.14x speedup on Octane/earley-boyer.js 2.04x speedup on MicroBench/for-of.js Note that MicroBench/for-of.js was more of a "set global" benchmark before this. After this change, it's actually a for..of benchmark. :^)
2025-05-01 23:58:38 +02:00
auto success = TRY(binding_object.internal_set(identifier, src, &binding_object, &cacheable_metadata));
LibJS: Mark more error paths in the interpreter as [[unlikely]]
2025-12-04 10:35:26 +01:00
if (!success && strict() == Strict::Yes) [[unlikely]] {
LibJS: Add SetGlobal bytecode instruction for cached global writes Before this change, setting a global would end up as SetLexicalBinding. That instruction always failed to cache the access if the global was a property of the global object. 1.14x speedup on Octane/earley-boyer.js 2.04x speedup on MicroBench/for-of.js Note that MicroBench/for-of.js was more of a "set global" benchmark before this. After this change, it's actually a for..of benchmark. :^)
2025-05-01 23:58:38 +02:00
// Note: Nothing like this in the spec, this is here to produce nicer errors instead of the generic one thrown by Object::set().
auto property_or_error = binding_object.internal_get_own_property(identifier);
if (!property_or_error.is_error()) {
auto property = property_or_error.release_value();
if (property.has_value() && !property->writable.value_or(true)) {
return vm.throw_completion<TypeError>(ErrorType::DescWriteNonWritable, identifier);
}
}
return vm.throw_completion<TypeError>(ErrorType::ObjectSetReturnedFalse);
}
LibJS: Add inline caching for adding new own properties to objects We already had IC support in PutById for the following cases: - Changing an existing own property - Calling a setter located in the prototype chain This was enough to speed up code where structurally identical objects (same shape) are processed in a loop: ```js const arr = [{ a: 1 }, { a: 2 }, { a: 3 }]; for (let obj of arr) { obj.a += 1; } ``` However, creating structurally identical objects in a loop was still slow: ```js for (let i = 0; i < 10_000_000; i++) { const o = {}; o.a = 1; o.b = 2; o.c = 3; } ``` This change addresses that by adding a new IC type that caches both the source and target shapes, allowing property additions to be fast-pathed by directly jumping to the shape that already includes the new property.
2025-09-15 17:23:39 +02:00
if (cacheable_metadata.type == CacheableSetPropertyMetadata::Type::ChangeOwnProperty) {
LibJS: Make GetById cache polymorphic Instead of monomorphic (1 shape), GetById inline caches are now polymorphic (4 shapes). This improves inline cache hit rates greatly on most web JavaScript. For example, Speedometer 2.1 sees 88% -> 97% cache hit rate improvement. 1.71x speedup on MicroBench/pic-get-own.js 1.82x speedup on MicroBench/pic-get-pchain.js
2025-05-06 13:16:44 +02:00
cache.entries[0].shape = shape;
cache.entries[0].property_offset = cacheable_metadata.property_offset.value();
LibJS: Track current shape dictionary generation in PropertyLookupCache When an object becomes too big (currently 64 properties or more), we change its shape to a dictionary and don't do any further transitions. However, this means the Shape of the object no longer changes, so the cache invalidation check of `current_shape != cache.shape` is no longer a valid check. This fixes that by keeping track of a generation number for the Shape both on the Shape object and in the cache, allowing that to be checked instead of the Shape identity. The generation is incremented whenever the dictionary is mutated. Fixes stale cache lookups on Gmail preventing emails from being displayed. I was not able to produce a reproduction for this, plus the generation count was over the 20k mark on Gmail.
2025-09-07 15:27:16 +01:00
if (shape.is_dictionary()) {
cache.entries[0].shape_dictionary_generation = shape.dictionary_generation();
}
LibJS: Add SetGlobal bytecode instruction for cached global writes Before this change, setting a global would end up as SetLexicalBinding. That instruction always failed to cache the access if the global was a property of the global object. 1.14x speedup on Octane/earley-boyer.js 2.04x speedup on MicroBench/for-of.js Note that MicroBench/for-of.js was more of a "set global" benchmark before this. After this change, it's actually a for..of benchmark. :^)
2025-05-01 23:58:38 +02:00
}
return {};
}
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
auto reference = TRY(vm.resolve_binding(identifier, strict(), &declarative_record));
LibJS: Add SetGlobal bytecode instruction for cached global writes Before this change, setting a global would end up as SetLexicalBinding. That instruction always failed to cache the access if the global was a property of the global object. 1.14x speedup on Octane/earley-boyer.js 2.04x speedup on MicroBench/for-of.js Note that MicroBench/for-of.js was more of a "set global" benchmark before this. After this change, it's actually a for..of benchmark. :^)
2025-05-01 23:58:38 +02:00
TRY(reference.put_value(vm, src));
return {};
}
LibJS: Mark `delete` operator instruction handlers COLD The delete operator is very rarely used in JavaScript, so let's keep it off the hot path.
2025-12-10 06:37:06 -06:00
COLD ThrowCompletionOr<void> DeleteVariable::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
auto& vm = interpreter.vm();
LibJS: Give Interpreter a direct pointer to the identifier table This gets rid of a lot of pointer chasing from interpreter to executable to identifier table to the actual identifier. 1.05x speed-up on Kraken/ai-astar.js
2025-10-07 16:47:41 +02:00
auto const& string = interpreter.get_identifier(m_identifier);
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
auto reference = TRY(vm.resolve_binding(string, strict()));
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(dst(), Value(TRY(reference.delete_(vm))));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
void CreateLexicalEnvironment::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
auto& parent = as<Environment>(interpreter.get(m_parent).as_cell());
auto environment = new_declarative_environment(parent);
environment->ensure_capacity(m_capacity);
interpreter.set(m_dst, environment);
interpreter.running_execution_context().lexical_environment = environment;
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
void CreatePrivateEnvironment::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Stop using execute_ast_node() for class property evaluation Instead, generate bytecode to execute their AST nodes and save the resulting operands inside the NewClass instruction. Moving property expression evaluation to happen before NewClass execution also moves along creation of new private environment and its population with private members (private members should be visible during property evaluation). Before: - NewClass After: - CreatePrivateEnvironment - AddPrivateName - ... - AddPrivateName - NewClass - LeavePrivateEnvironment
2024-05-11 22:54:41 +00:00
{
auto& running_execution_context = interpreter.vm().running_execution_context();
auto outer_private_environment = running_execution_context.private_environment;
running_execution_context.private_environment = new_private_environment(interpreter.vm(), outer_private_environment);
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
void CreateVariableEnvironment::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
{
LibJS/Bytecode: Cache the running execution context in interpreter
2024-05-11 18:16:27 +02:00
auto& running_execution_context = interpreter.running_execution_context();
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
auto var_environment = new_declarative_environment(*running_execution_context.lexical_environment);
LibJS: Ensure capacity for created lexical and variable environments If the minimal amount of required bindings is known in advance, it could be used to ensure capacity to avoid resizing the internal vector that holds bindings.
2024-05-09 17:10:20 +02:00
var_environment->ensure_capacity(m_capacity);
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
running_execution_context.variable_environment = var_environment;
running_execution_context.lexical_environment = var_environment;
}
LibJS: Mark three uncommon instruction handlers COLD - with statement - throw statement - catch statement All of these should be rare cases (especially with!)
2025-12-09 17:39:00 -06:00
COLD ThrowCompletionOr<void> EnterObjectEnvironment::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto object = TRY(interpreter.get(m_object).to_object(interpreter.vm()));
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
auto& old_environment = interpreter.running_execution_context().lexical_environment;
auto new_environment = new_object_environment(*object, true, old_environment);
interpreter.set(m_dst, new_environment);
interpreter.running_execution_context().lexical_environment = new_environment;
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return {};
}
LibJS: Mark three uncommon instruction handlers COLD - with statement - throw statement - catch statement All of these should be rare cases (especially with!)
2025-12-09 17:39:00 -06:00
COLD void Catch::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS/JIT: Update "unwind context" stack in JIT code Until now, the unwind context stack has not been maintained by jitted code, which meant we were unable to support the `with` statement. This is a first step towards supporting that by making jitted code call out to C++ to update the unwind context stack when entering/leaving unwind contexts. We also introduce a new "Catch" bytecode instruction that moves the current exception into the accumulator. It's always emitted at the start of a "catch" block.
2023-11-11 23:19:46 +01:00
{
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.catch_exception(dst());
LibJS/JIT: Update "unwind context" stack in JIT code Until now, the unwind context stack has not been maintained by jitted code, which meant we were unable to support the `with` statement. This is a first step towards supporting that by making jitted code call out to C++ to update the unwind context stack when entering/leaving unwind contexts. We also introduce a new "Catch" bytecode instruction that moves the current exception into the accumulator. It's always emitted at the start of a "catch" block.
2023-11-11 23:19:46 +01:00
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> CreateVariable::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
LibJS: Give Interpreter a direct pointer to the identifier table This gets rid of a lot of pointer chasing from interpreter to executable to identifier table to the actual identifier. 1.05x speed-up on Kraken/ai-astar.js
2025-10-07 16:47:41 +02:00
auto const& name = interpreter.get_identifier(m_identifier);
LibJS/Bytecode: Move CreateVariable impl to CommonImplementations
2023-10-29 00:21:43 +02:00
return create_variable(interpreter.vm(), name, m_mode, m_is_global, m_is_immutable, m_is_strict);
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
void CreateRestParams::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
{
LibJS: Cache arguments span in ExecutionContext Allows us to avoid doing math in ExecutionContext::argument()
2025-04-24 01:37:30 +02:00
auto const arguments = interpreter.running_execution_context().arguments;
LibJS/Bytecode: Cache the running execution context in interpreter
2024-05-11 18:16:27 +02:00
auto arguments_count = interpreter.running_execution_context().passed_argument_count;
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
auto array = MUST(Array::create(interpreter.realm(), 0));
for (size_t rest_index = m_rest_index; rest_index < arguments_count; ++rest_index)
array->indexed_properties().append(arguments[rest_index]);
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, array);
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
void CreateArguments::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
{
LibJS/Bytecode: Cache the running execution context in interpreter
2024-05-11 18:16:27 +02:00
auto const& function = interpreter.running_execution_context().function;
LibJS: Cache arguments span in ExecutionContext Allows us to avoid doing math in ExecutionContext::argument()
2025-04-24 01:37:30 +02:00
auto const arguments = interpreter.running_execution_context().arguments;
LibJS/Bytecode: Cache the running execution context in interpreter
2024-05-11 18:16:27 +02:00
auto const& environment = interpreter.running_execution_context().lexical_environment;
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
LibJS/Bytecode: Cache the running execution context in interpreter
2024-05-11 18:16:27 +02:00
auto passed_arguments = ReadonlySpan<Value> { arguments.data(), interpreter.running_execution_context().passed_argument_count };
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
Object* arguments_object;
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
if (m_kind == ArgumentsKind::Mapped) {
LibJS: Pre-store formal parameter runtime data Replace the runtime uses of formal_parameters() with pre-computed data: - m_formal_parameter_count stores the parameter count - m_parameter_names_for_mapped_arguments stores ordered parameter names for simple parameter lists (used by create_mapped_arguments_object) Change create_mapped_arguments_object to take Span<Utf16FlyString> instead of NonnullRefPtr<FunctionParameters const>. Remove virtual formal_parameters() from FunctionObject as it is no longer needed.
2026-02-11 01:13:06 +01:00
auto const& ecma_function = static_cast<ECMAScriptFunctionObject const&>(*function);
arguments_object = create_mapped_arguments_object(interpreter.vm(), *function, ecma_function.parameter_names_for_mapped_arguments(), passed_arguments, *environment);
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
} else {
arguments_object = create_unmapped_arguments_object(interpreter.vm(), passed_arguments);
}
LibJS: Use a local variable for arguments object when possible This allows us to skip allocating a function environment in cases where it was previously impossible because the arguments object needed a binding. This change does not bring visible improvement in Kraken or Octane benchmarks but seems useful to have anyway.
2024-05-21 09:32:51 +01:00
if (m_dst.has_value()) {
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(*m_dst, arguments_object);
LibJS: Remove unnecessary exception checks in bytecode dispatch No need to check for exceptions after instructions that cannot throw.
2025-04-04 13:48:59 +02:00
return;
LibJS: Use a local variable for arguments object when possible This allows us to skip allocating a function environment in cases where it was previously impossible because the arguments object needed a binding. This change does not bring visible improvement in Kraken or Octane benchmarks but seems useful to have anyway.
2024-05-21 09:32:51 +01:00
}
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
if (m_is_immutable) {
MUST(environment->create_immutable_binding(interpreter.vm(), interpreter.vm().names.arguments.as_string(), false));
} else {
MUST(environment->create_mutable_binding(interpreter.vm(), interpreter.vm().names.arguments.as_string(), false));
}
MUST(environment->initialize_binding(interpreter.vm(), interpreter.vm().names.arguments.as_string(), arguments_object, Environment::InitializeBindingHint::Normal));
}
LibJS/Bytecode: Split SetVariable into four separate instructions Instead of SetVariable having 2x2 modes for variable/lexical and initialize/set, those 4 modes are now separate instructions, which makes each instruction much less branchy.
2024-05-14 11:30:30 +02:00
template<EnvironmentMode environment_mode, BindingInitializationMode initialization_mode>
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
static ThrowCompletionOr<void> initialize_or_set_binding(Interpreter& interpreter, IdentifierTableIndex identifier_index, Strict strict, Value value, EnvironmentCoordinate& cache)
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
auto& vm = interpreter.vm();
LibJS/Bytecode: Add environment coordinate caching to SetVariable This means that SetVariable instructions will now remember which (relative) environment contains the targeted binding, letting it bypass the full binding resolution machinery on subsequent accesses.
2024-05-13 22:03:52 +02:00
LibJS/Bytecode: Split SetVariable into four separate instructions Instead of SetVariable having 2x2 modes for variable/lexical and initialize/set, those 4 modes are now separate instructions, which makes each instruction much less branchy.
2024-05-14 11:30:30 +02:00
auto* environment = environment_mode == EnvironmentMode::Lexical
? interpreter.running_execution_context().lexical_environment.ptr()
: interpreter.running_execution_context().variable_environment.ptr();
LibJS: Use [[likely]] annotations for cached environment lookups These will generally be cached the vast majority of the time except on first encounter, and sprinkling [[likely]] gives us a nice boost. 1.10x speed-up on this micro-benchmark: (() => { var a = 3; for (let i = 0; i < 100_000_000; ++i) { a; } eval(""); })();
2025-10-07 16:37:22 +02:00
if (cache.is_valid()) [[likely]] {
LibJS: Limit eval() deoptimization to the containing function scope Previously, when direct eval() was called, we would mark the entire environment chain as "permanently screwed by eval", disabling variable access caching all the way up to the global scope. This was overly conservative. According to the ECMAScript specification, a sloppy direct eval() can only inject var declarations into its containing function's variable environment - it cannot inject variables into parent function scopes. This patch makes two changes: 1. Stop propagating the "screwed by eval" flag at function boundaries. When set_permanently_screwed_by_eval() hits a FunctionEnvironment or GlobalEnvironment, it no longer continues to outer environments. 2. Check each environment during cache lookup traversal. If any environment in the path is marked as screwed, we bail to the slow path. This catches the case where we're inside a function with eval and have a cached coordinate pointing to an outer scope. The second change is necessary because eval can create local variables that shadow outer bindings. When looking up a variable from inside a function that called eval, we can't trust cached coordinates that point to outer scopes, since eval may have created a closer binding. This improves performance for code with nested functions where an inner function uses eval but parent functions perform many variable accesses. The parent functions can now use cached environment coordinates. All 29 new tests verify behavior matches V8.
2026-01-26 20:40:05 +01:00
for (size_t i = 0; i < cache.hops; ++i) {
if (environment->is_permanently_screwed_by_eval()) [[unlikely]]
goto slow_path;
LibJS/Bytecode: Add environment coordinate caching to SetVariable This means that SetVariable instructions will now remember which (relative) environment contains the targeted binding, letting it bypass the full binding resolution machinery on subsequent accesses.
2024-05-13 22:03:52 +02:00
environment = environment->outer_environment();
LibJS: Limit eval() deoptimization to the containing function scope Previously, when direct eval() was called, we would mark the entire environment chain as "permanently screwed by eval", disabling variable access caching all the way up to the global scope. This was overly conservative. According to the ECMAScript specification, a sloppy direct eval() can only inject var declarations into its containing function's variable environment - it cannot inject variables into parent function scopes. This patch makes two changes: 1. Stop propagating the "screwed by eval" flag at function boundaries. When set_permanently_screwed_by_eval() hits a FunctionEnvironment or GlobalEnvironment, it no longer continues to outer environments. 2. Check each environment during cache lookup traversal. If any environment in the path is marked as screwed, we bail to the slow path. This catches the case where we're inside a function with eval and have a cached coordinate pointing to an outer scope. The second change is necessary because eval can create local variables that shadow outer bindings. When looking up a variable from inside a function that called eval, we can't trust cached coordinates that point to outer scopes, since eval may have created a closer binding. This improves performance for code with nested functions where an inner function uses eval but parent functions perform many variable accesses. The parent functions can now use cached environment coordinates. All 29 new tests verify behavior matches V8.
2026-01-26 20:40:05 +01:00
}
LibJS: Use [[likely]] annotations for cached environment lookups These will generally be cached the vast majority of the time except on first encounter, and sprinkling [[likely]] gives us a nice boost. 1.10x speed-up on this micro-benchmark: (() => { var a = 3; for (let i = 0; i < 100_000_000; ++i) { a; } eval(""); })();
2025-10-07 16:37:22 +02:00
if (!environment->is_permanently_screwed_by_eval()) [[likely]] {
LibJS/Bytecode: Split SetVariable into four separate instructions Instead of SetVariable having 2x2 modes for variable/lexical and initialize/set, those 4 modes are now separate instructions, which makes each instruction much less branchy.
2024-05-14 11:30:30 +02:00
if constexpr (initialization_mode == BindingInitializationMode::Initialize) {
TRY(static_cast<DeclarativeEnvironment&>(*environment).initialize_binding_direct(vm, cache.index, value, Environment::InitializeBindingHint::Normal));
} else {
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
TRY(static_cast<DeclarativeEnvironment&>(*environment).set_mutable_binding_direct(vm, cache.index, value, strict == Strict::Yes));
LibJS/Bytecode: Add environment coordinate caching to SetVariable This means that SetVariable instructions will now remember which (relative) environment contains the targeted binding, letting it bypass the full binding resolution machinery on subsequent accesses.
2024-05-13 22:03:52 +02:00
}
return {};
}
LibJS: Limit eval() deoptimization to the containing function scope Previously, when direct eval() was called, we would mark the entire environment chain as "permanently screwed by eval", disabling variable access caching all the way up to the global scope. This was overly conservative. According to the ECMAScript specification, a sloppy direct eval() can only inject var declarations into its containing function's variable environment - it cannot inject variables into parent function scopes. This patch makes two changes: 1. Stop propagating the "screwed by eval" flag at function boundaries. When set_permanently_screwed_by_eval() hits a FunctionEnvironment or GlobalEnvironment, it no longer continues to outer environments. 2. Check each environment during cache lookup traversal. If any environment in the path is marked as screwed, we bail to the slow path. This catches the case where we're inside a function with eval and have a cached coordinate pointing to an outer scope. The second change is necessary because eval can create local variables that shadow outer bindings. When looking up a variable from inside a function that called eval, we can't trust cached coordinates that point to outer scopes, since eval may have created a closer binding. This improves performance for code with nested functions where an inner function uses eval but parent functions perform many variable accesses. The parent functions can now use cached environment coordinates. All 29 new tests verify behavior matches V8.
2026-01-26 20:40:05 +01:00
slow_path:
LibJS/Bytecode: Split SetVariable into four separate instructions Instead of SetVariable having 2x2 modes for variable/lexical and initialize/set, those 4 modes are now separate instructions, which makes each instruction much less branchy.
2024-05-14 11:30:30 +02:00
cache = {};
LibJS/Bytecode: Add environment coordinate caching to SetVariable This means that SetVariable instructions will now remember which (relative) environment contains the targeted binding, letting it bypass the full binding resolution machinery on subsequent accesses.
2024-05-13 22:03:52 +02:00
}
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
auto reference = TRY(vm.resolve_binding(interpreter.get_identifier(identifier_index), strict, environment));
LibJS/Bytecode: Split SetVariable into four separate instructions Instead of SetVariable having 2x2 modes for variable/lexical and initialize/set, those 4 modes are now separate instructions, which makes each instruction much less branchy.
2024-05-14 11:30:30 +02:00
if (reference.environment_coordinate().has_value())
cache = reference.environment_coordinate().value();
if constexpr (initialization_mode == BindingInitializationMode::Initialize) {
TRY(reference.initialize_referenced_binding(vm, value));
} else if (initialization_mode == BindingInitializationMode::Set) {
TRY(reference.put_value(vm, value));
}
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> InitializeLexicalBinding::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS/Bytecode: Split SetVariable into four separate instructions Instead of SetVariable having 2x2 modes for variable/lexical and initialize/set, those 4 modes are now separate instructions, which makes each instruction much less branchy.
2024-05-14 11:30:30 +02:00
{
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
return initialize_or_set_binding<EnvironmentMode::Lexical, BindingInitializationMode::Initialize>(interpreter, m_identifier, strict(), interpreter.get(m_src), m_cache);
LibJS/Bytecode: Split SetVariable into four separate instructions Instead of SetVariable having 2x2 modes for variable/lexical and initialize/set, those 4 modes are now separate instructions, which makes each instruction much less branchy.
2024-05-14 11:30:30 +02:00
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> InitializeVariableBinding::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS/Bytecode: Split SetVariable into four separate instructions Instead of SetVariable having 2x2 modes for variable/lexical and initialize/set, those 4 modes are now separate instructions, which makes each instruction much less branchy.
2024-05-14 11:30:30 +02:00
{
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
return initialize_or_set_binding<EnvironmentMode::Var, BindingInitializationMode::Initialize>(interpreter, m_identifier, strict(), interpreter.get(m_src), m_cache);
LibJS/Bytecode: Split SetVariable into four separate instructions Instead of SetVariable having 2x2 modes for variable/lexical and initialize/set, those 4 modes are now separate instructions, which makes each instruction much less branchy.
2024-05-14 11:30:30 +02:00
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> SetLexicalBinding::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS/Bytecode: Split SetVariable into four separate instructions Instead of SetVariable having 2x2 modes for variable/lexical and initialize/set, those 4 modes are now separate instructions, which makes each instruction much less branchy.
2024-05-14 11:30:30 +02:00
{
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
return initialize_or_set_binding<EnvironmentMode::Lexical, BindingInitializationMode::Set>(interpreter, m_identifier, strict(), interpreter.get(m_src), m_cache);
LibJS/Bytecode: Split SetVariable into four separate instructions Instead of SetVariable having 2x2 modes for variable/lexical and initialize/set, those 4 modes are now separate instructions, which makes each instruction much less branchy.
2024-05-14 11:30:30 +02:00
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> SetVariableBinding::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS/Bytecode: Split SetVariable into four separate instructions Instead of SetVariable having 2x2 modes for variable/lexical and initialize/set, those 4 modes are now separate instructions, which makes each instruction much less branchy.
2024-05-14 11:30:30 +02:00
{
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
return initialize_or_set_binding<EnvironmentMode::Var, BindingInitializationMode::Set>(interpreter, m_identifier, strict(), interpreter.get(m_src), m_cache);
LibJS/Bytecode: Split SetVariable into four separate instructions Instead of SetVariable having 2x2 modes for variable/lexical and initialize/set, those 4 modes are now separate instructions, which makes each instruction much less branchy.
2024-05-14 11:30:30 +02:00
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> GetById::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto base_value = interpreter.get(base());
LibJS: Store cache pointers directly in bytecode instructions Instead of storing a u32 index into a cache vector and looking up the cache at runtime through a chain of dependent loads (load Executable*, load vector data pointer, multiply index, add), store the actual cache pointer as a u64 directly in the instruction stream. A fixup pass (Executable::fixup_cache_pointers()) runs after Executable construction in both the Rust and C++ pipelines, walking the bytecode and replacing each index with the corresponding pointer. The cache pointer type is encoded in Bytecode.def (e.g. PropertyLookupCache*, GlobalVariableCache*) so the fixup switch is auto-generated by the Python Op code generator, making it impossible to forget updating the fixup when adding new cached instructions. This eliminates 3-4 dependent loads on every inline cache access in both the C++ interpreter and the assembly interpreter.
2026-03-07 22:52:25 +01:00
auto& cache = *bit_cast<PropertyLookupCache*>(m_cache);
LibJS: Include identifier information in nullish property read access When a GetById / GetByValue bytecode operation results in accessing a nullish object, we now include the name of the property and the object being accessed in the exception message (if available). This should make it easier to debug live websites. For example, the following errors would all previously produce a generic error message of "ToObject on null or undefined": > foo = null > foo.bar Uncaught exception: [TypeError] Cannot access property "bar" on null object "foo" at <unknown> > foo = { bar: undefined } > foo.bar.baz Uncaught exception: [TypeError] Cannot access property "baz" on undefined object "foo.bar" at <unknown> Note we certainly don't capture all possible nullish property read accesses here. This just covers cases I've seen most on live websites; we can cover more cases as they arise.
2024-03-29 11:26:10 -04:00
LibJS: Avoid three PropertyKey copies in the interpreter
2025-12-13 23:01:24 -06:00
interpreter.set(dst(), TRY(get_by_id<GetByIdMode::Normal>(interpreter.vm(), [&] { return interpreter.get_identifier(m_base_identifier); }, [&] -> PropertyKey const& { return interpreter.get_property_key(m_property); }, base_value, base_value, cache)));
LibJS/Bytecode: Begin moving shareable (JIT+Interpreter) stuff somewhere There are a lot of native C++ functions that will be used by both the bytecode interpreter and jitted code. Let's put them in their own file instead of having them in Interpreter.cpp.
2023-10-18 13:26:47 +02:00
return {};
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> GetByIdWithThis::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto base_value = interpreter.get(m_base);
auto this_value = interpreter.get(m_this_value);
LibJS: Store cache pointers directly in bytecode instructions Instead of storing a u32 index into a cache vector and looking up the cache at runtime through a chain of dependent loads (load Executable*, load vector data pointer, multiply index, add), store the actual cache pointer as a u64 directly in the instruction stream. A fixup pass (Executable::fixup_cache_pointers()) runs after Executable construction in both the Rust and C++ pipelines, walking the bytecode and replacing each index with the corresponding pointer. The cache pointer type is encoded in Bytecode.def (e.g. PropertyLookupCache*, GlobalVariableCache*) so the fixup switch is auto-generated by the Python Op code generator, making it impossible to forget updating the fixup when adding new cached instructions. This eliminates 3-4 dependent loads on every inline cache access in both the C++ interpreter and the assembly interpreter.
2026-03-07 22:52:25 +01:00
auto& cache = *bit_cast<PropertyLookupCache*>(m_cache);
LibJS: Avoid three PropertyKey copies in the interpreter
2025-12-13 23:01:24 -06:00
interpreter.set(dst(), TRY(get_by_id<GetByIdMode::Normal>(interpreter.vm(), [] { return Optional<Utf16FlyString const&> {}; }, [&] -> PropertyKey const& { return interpreter.get_property_key(m_property); }, base_value, this_value, cache)));
LibJS/Bytecode: Begin moving shareable (JIT+Interpreter) stuff somewhere There are a lot of native C++ functions that will be used by both the bytecode interpreter and jitted code. Let's put them in their own file instead of having them in Interpreter.cpp.
2023-10-18 13:26:47 +02:00
return {};
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> GetLength::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS/Bytecode: Add dedicated instruction for getting `length` property By doing this, we can remove all the special-case checks for `length` from the generic GetById and GetByIdWithThis code paths, making every other property lookup a bit faster. Small progressions on most benchmarks, and some larger progressions: - 12% on Octane/crypto.js - 6% on Kraken/ai-astar.js
2024-05-20 11:53:28 +02:00
{
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto base_value = interpreter.get(base());
LibJS: Make GetById and GetByValue avoid get_identifier() in common case We now defer looking up the various identifiers by IdentifierTableIndex until the last moment. This allows us to avoid the retrieval in common cases like when a property access is cached. Knocks a ~12% item off the profile on https://ventrella.com/Clusters/
2024-07-09 11:37:06 +02:00
auto& executable = interpreter.current_executable();
LibJS: Store cache pointers directly in bytecode instructions Instead of storing a u32 index into a cache vector and looking up the cache at runtime through a chain of dependent loads (load Executable*, load vector data pointer, multiply index, add), store the actual cache pointer as a u64 directly in the instruction stream. A fixup pass (Executable::fixup_cache_pointers()) runs after Executable construction in both the Rust and C++ pipelines, walking the bytecode and replacing each index with the corresponding pointer. The cache pointer type is encoded in Bytecode.def (e.g. PropertyLookupCache*, GlobalVariableCache*) so the fixup switch is auto-generated by the Python Op code generator, making it impossible to forget updating the fixup when adding new cached instructions. This eliminates 3-4 dependent loads on every inline cache access in both the C++ interpreter and the assembly interpreter.
2026-03-07 22:52:25 +01:00
auto& cache = *bit_cast<PropertyLookupCache*>(m_cache);
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
interpreter.set(dst(), TRY(get_by_id<GetByIdMode::Length>(interpreter.vm(), [&] { return interpreter.get_identifier(m_base_identifier); }, [&] { return executable.get_property_key(*executable.length_identifier); }, base_value, base_value, cache)));
LibJS/Bytecode: Add dedicated instruction for getting `length` property By doing this, we can remove all the special-case checks for `length` from the generic GetById and GetByIdWithThis code paths, making every other property lookup a bit faster. Small progressions on most benchmarks, and some larger progressions: - 12% on Octane/crypto.js - 6% on Kraken/ai-astar.js
2024-05-20 11:53:28 +02:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> GetLengthWithThis::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS/Bytecode: Add dedicated instruction for getting `length` property By doing this, we can remove all the special-case checks for `length` from the generic GetById and GetByIdWithThis code paths, making every other property lookup a bit faster. Small progressions on most benchmarks, and some larger progressions: - 12% on Octane/crypto.js - 6% on Kraken/ai-astar.js
2024-05-20 11:53:28 +02:00
{
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto base_value = interpreter.get(m_base);
auto this_value = interpreter.get(m_this_value);
LibJS: Make GetById and GetByValue avoid get_identifier() in common case We now defer looking up the various identifiers by IdentifierTableIndex until the last moment. This allows us to avoid the retrieval in common cases like when a property access is cached. Knocks a ~12% item off the profile on https://ventrella.com/Clusters/
2024-07-09 11:37:06 +02:00
auto& executable = interpreter.current_executable();
LibJS: Store cache pointers directly in bytecode instructions Instead of storing a u32 index into a cache vector and looking up the cache at runtime through a chain of dependent loads (load Executable*, load vector data pointer, multiply index, add), store the actual cache pointer as a u64 directly in the instruction stream. A fixup pass (Executable::fixup_cache_pointers()) runs after Executable construction in both the Rust and C++ pipelines, walking the bytecode and replacing each index with the corresponding pointer. The cache pointer type is encoded in Bytecode.def (e.g. PropertyLookupCache*, GlobalVariableCache*) so the fixup switch is auto-generated by the Python Op code generator, making it impossible to forget updating the fixup when adding new cached instructions. This eliminates 3-4 dependent loads on every inline cache access in both the C++ interpreter and the assembly interpreter.
2026-03-07 22:52:25 +01:00
auto& cache = *bit_cast<PropertyLookupCache*>(m_cache);
LibJS: Avoid three PropertyKey copies in the interpreter
2025-12-13 23:01:24 -06:00
interpreter.set(dst(), TRY(get_by_id<GetByIdMode::Length>(interpreter.vm(), [] { return Optional<Utf16FlyString const&> {}; }, [&] -> PropertyKey const& { return executable.get_property_key(*executable.length_identifier); }, base_value, this_value, cache)));
LibJS/Bytecode: Add dedicated instruction for getting `length` property By doing this, we can remove all the special-case checks for `length` from the generic GetById and GetByIdWithThis code paths, making every other property lookup a bit faster. Small progressions on most benchmarks, and some larger progressions: - 12% on Octane/crypto.js - 6% on Kraken/ai-astar.js
2024-05-20 11:53:28 +02:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> GetPrivateById::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
auto& vm = interpreter.vm();
LibJS: Give Interpreter a direct pointer to the identifier table This gets rid of a lot of pointer chasing from interpreter to executable to identifier table to the actual identifier. 1.05x speed-up on Kraken/ai-astar.js
2025-10-07 16:47:41 +02:00
auto const& name = interpreter.get_identifier(m_property);
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto base_value = interpreter.get(m_base);
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
auto private_reference = make_private_reference(vm, base_value, name);
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(dst(), TRY(private_reference.get_value(vm)));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> HasPrivateId::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
auto& vm = interpreter.vm();
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto base = interpreter.get(m_base);
LibJS: Mark more error paths in the interpreter as [[unlikely]]
2025-12-04 10:35:26 +01:00
if (!base.is_object()) [[unlikely]]
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return vm.throw_completion<TypeError>(ErrorType::InOperatorWithObject);
LibJS/Bytecode: Cache the running execution context in interpreter
2024-05-11 18:16:27 +02:00
auto private_environment = interpreter.running_execution_context().private_environment;
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
VERIFY(private_environment);
LibJS: Give Interpreter a direct pointer to the identifier table This gets rid of a lot of pointer chasing from interpreter to executable to identifier table to the actual identifier. 1.05x speed-up on Kraken/ai-astar.js
2025-10-07 16:47:41 +02:00
auto private_name = private_environment->resolve_private_identifier(interpreter.get_identifier(m_property));
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(dst(), Value(base.as_object().private_element_find(private_name) != nullptr));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> PutBySpread::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Add `PutBySpread` instruction This object property kind had completely different behaviour. By adding an instruction for it, we can remove a bunch of special casing, and avoid creating dummy `PropertyKey` values.
2024-11-01 22:00:32 +01:00
{
auto& vm = interpreter.vm();
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto value = interpreter.get(m_src);
auto base = interpreter.get(m_base);
LibJS: Add `PutBySpread` instruction This object property kind had completely different behaviour. By adding an instruction for it, we can remove a bunch of special casing, and avoid creating dummy `PropertyKey` values.
2024-11-01 22:00:32 +01:00
// a. Let baseObj be ? ToObject(V.[[Base]]).
auto object = TRY(base.to_object(vm));
TRY(object->copy_data_properties(vm, value, {}));
return {};
}
LibJS: Consolidate Put bytecode instructions and reduce code bloat Replace 20 separate Put instructions (5 PutKinds x 4 forms) with 4 unified instructions (PutById, PutByIdWithThis, PutByValue, PutByValueWithThis), each carrying a PutKind field at runtime instead of being a separate opcode. This reduces the number of handler entry points in the dispatch loop and eliminates template instantiations of put_by_property_key and put_by_value that were being duplicated 5x each when inlined by LTO.
2026-03-04 10:33:38 +01:00
ThrowCompletionOr<void> PutById::execute_impl(Bytecode::Interpreter& interpreter) const
{
auto& vm = interpreter.vm();
auto value = interpreter.get(m_src);
auto base = interpreter.get(m_base);
auto const& base_identifier = interpreter.get_identifier(m_base_identifier);
auto const& property_key = interpreter.get_property_key(m_property);
LibJS: Store cache pointers directly in bytecode instructions Instead of storing a u32 index into a cache vector and looking up the cache at runtime through a chain of dependent loads (load Executable*, load vector data pointer, multiply index, add), store the actual cache pointer as a u64 directly in the instruction stream. A fixup pass (Executable::fixup_cache_pointers()) runs after Executable construction in both the Rust and C++ pipelines, walking the bytecode and replacing each index with the corresponding pointer. The cache pointer type is encoded in Bytecode.def (e.g. PropertyLookupCache*, GlobalVariableCache*) so the fixup switch is auto-generated by the Python Op code generator, making it impossible to forget updating the fixup when adding new cached instructions. This eliminates 3-4 dependent loads on every inline cache access in both the C++ interpreter and the assembly interpreter.
2026-03-07 22:52:25 +01:00
auto& cache = *bit_cast<PropertyLookupCache*>(m_cache);
LibJS: Consolidate Put bytecode instructions and reduce code bloat Replace 20 separate Put instructions (5 PutKinds x 4 forms) with 4 unified instructions (PutById, PutByIdWithThis, PutByValue, PutByValueWithThis), each carrying a PutKind field at runtime instead of being a separate opcode. This reduces the number of handler entry points in the dispatch loop and eliminates template instantiations of put_by_property_key and put_by_value that were being duplicated 5x each when inlined by LTO.
2026-03-04 10:33:38 +01:00
TRY(put_by_property_key(vm, base, base, value, base_identifier, property_key, m_kind, strict(), &cache));
return {};
}
LibJS: Split PutBy* instructions into specialized per-kind variants This allows the compiler to fold away lots of unused code for each kind. 1.10x speed-up on MicroBench/pic-add-own.js :^)
2025-10-10 12:09:34 +02:00
LibJS: Consolidate Put bytecode instructions and reduce code bloat Replace 20 separate Put instructions (5 PutKinds x 4 forms) with 4 unified instructions (PutById, PutByIdWithThis, PutByValue, PutByValueWithThis), each carrying a PutKind field at runtime instead of being a separate opcode. This reduces the number of handler entry points in the dispatch loop and eliminates template instantiations of put_by_property_key and put_by_value that were being duplicated 5x each when inlined by LTO.
2026-03-04 10:33:38 +01:00
ThrowCompletionOr<void> PutByIdWithThis::execute_impl(Bytecode::Interpreter& interpreter) const
{
auto& vm = interpreter.vm();
auto value = interpreter.get(m_src);
auto base = interpreter.get(m_base);
auto const& name = interpreter.get_property_key(m_property);
LibJS: Store cache pointers directly in bytecode instructions Instead of storing a u32 index into a cache vector and looking up the cache at runtime through a chain of dependent loads (load Executable*, load vector data pointer, multiply index, add), store the actual cache pointer as a u64 directly in the instruction stream. A fixup pass (Executable::fixup_cache_pointers()) runs after Executable construction in both the Rust and C++ pipelines, walking the bytecode and replacing each index with the corresponding pointer. The cache pointer type is encoded in Bytecode.def (e.g. PropertyLookupCache*, GlobalVariableCache*) so the fixup switch is auto-generated by the Python Op code generator, making it impossible to forget updating the fixup when adding new cached instructions. This eliminates 3-4 dependent loads on every inline cache access in both the C++ interpreter and the assembly interpreter.
2026-03-07 22:52:25 +01:00
auto& cache = *bit_cast<PropertyLookupCache*>(m_cache);
LibJS: Consolidate Put bytecode instructions and reduce code bloat Replace 20 separate Put instructions (5 PutKinds x 4 forms) with 4 unified instructions (PutById, PutByIdWithThis, PutByValue, PutByValueWithThis), each carrying a PutKind field at runtime instead of being a separate opcode. This reduces the number of handler entry points in the dispatch loop and eliminates template instantiations of put_by_property_key and put_by_value that were being duplicated 5x each when inlined by LTO.
2026-03-04 10:33:38 +01:00
TRY(put_by_property_key(vm, base, interpreter.get(m_this_value), value, {}, name, m_kind, strict(), &cache));
return {};
}
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> PutPrivateById::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
auto& vm = interpreter.vm();
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto value = interpreter.get(m_src);
auto object = TRY(interpreter.get(m_base).to_object(vm));
LibJS: Avoid Utf16FlyString copy constructors in the interpreter Just a minor thing to reduce code bloat.
2025-12-04 09:20:30 +01:00
auto const& name = interpreter.get_identifier(m_property);
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
auto private_reference = make_private_reference(vm, object, name);
TRY(private_reference.put_value(vm, value));
return {};
}
LibJS: Mark `delete` operator instruction handlers COLD The delete operator is very rarely used in JavaScript, so let's keep it off the hot path.
2025-12-10 06:37:06 -06:00
COLD ThrowCompletionOr<void> DeleteById::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
auto& vm = interpreter.vm();
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
auto const& property_key = interpreter.get_property_key(m_property);
auto reference = Reference { interpreter.get(m_base), property_key, {}, strict() };
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
interpreter.set(dst(), Value(TRY(reference.delete_(vm))));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> ResolveThisBinding::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
auto& cached_this_value = interpreter.reg(Register::this_value());
LibJS: Make Value() default-construct the undefined value The special empty value (that we use for array holes, Optional<Value> when empty and a few other other placeholder/sentinel tasks) still exists, but you now create one via JS::js_special_empty_value() and check for it with Value::is_special_empty_value(). The main idea here is to make it very unlikely to accidentally create an unexpected special empty value.
2025-04-04 23:16:34 +02:00
if (!cached_this_value.is_special_empty_value())
LibJS/Bytecode: Always resolve `this` binding into dedicated register We already have a dedicated register slot for `this`, so instead of having ResolveThisBinding take a `dst` operand, just write the value directly into the `this` register every time.
2024-05-31 20:41:29 +02:00
return {};
// OPTIMIZATION: Because the value of 'this' cannot be reassigned during a function execution, it's
// resolved once and then saved for subsequent use.
auto& running_execution_context = interpreter.running_execution_context();
if (auto function = running_execution_context.function; function && is<ECMAScriptFunctionObject>(*function) && !static_cast<ECMAScriptFunctionObject&>(*function).allocates_function_environment()) {
LibJS: Make Value() default-construct the undefined value The special empty value (that we use for array holes, Optional<Value> when empty and a few other other placeholder/sentinel tasks) still exists, but you now create one via JS::js_special_empty_value() and check for it with Value::is_special_empty_value(). The main idea here is to make it very unlikely to accidentally create an unexpected special empty value.
2025-04-04 23:16:34 +02:00
cached_this_value = running_execution_context.this_value.value();
LibJS/Bytecode: Always resolve `this` binding into dedicated register We already have a dedicated register slot for `this`, so instead of having ResolveThisBinding take a `dst` operand, just write the value directly into the `this` register every time.
2024-05-31 20:41:29 +02:00
} else {
auto& vm = interpreter.vm();
cached_this_value = TRY(vm.resolve_this_binding());
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
return {};
}
// https://tc39.es/ecma262/#sec-makesuperpropertyreference
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> ResolveSuperBase::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
auto& vm = interpreter.vm();
// 1. Let env be GetThisEnvironment().
AK+Everywhere: Rename `verify_cast` to `as` Follow-up to fc20e61e7249006247b43f84a3189d5a37fa103e.
2025-01-21 09:12:05 -05:00
auto& env = as<FunctionEnvironment>(*get_this_environment(vm));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
// 2. Assert: env.HasSuperBinding() is true.
VERIFY(env.has_super_binding());
// 3. Let baseValue be ? env.GetSuperBase().
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(dst(), TRY(env.get_super_base()));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
void GetNewTarget::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(dst(), interpreter.vm().get_new_target());
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
void GetImportMeta::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(dst(), interpreter.vm().get_import_meta());
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
void GetLexicalEnvironment::execute_impl(Bytecode::Interpreter& interpreter) const
{
interpreter.set(dst(), interpreter.running_execution_context().lexical_environment);
}
void SetLexicalEnvironment::execute_impl(Bytecode::Interpreter& interpreter) const
{
interpreter.running_execution_context().lexical_environment = &as<Environment>(interpreter.get(m_environment).as_cell());
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
static ThrowCompletionOr<Value> dispatch_builtin_call(Bytecode::Interpreter& interpreter, Bytecode::Builtin builtin, ReadonlySpan<Operand> arguments)
LibJS: Call builtins directly in the bytecode interpreter Allows the bytecode interpreter to call the builtins c++ implementation directly without making a javascript call just as the JIT. Kraken test speedups: imaging-gaussian-blur.js (1.5x) and audio-oscillator.js (1.2x)
2023-11-30 19:49:29 +01:00
{
switch (builtin) {
case Builtin::MathAbs:
LibJS: Skip some hot bounds checks in the interpreter Let's allow ourselves to trust the number of property lookup caches present, along with a few other things.
2025-12-13 23:09:24 -06:00
return TRY(MathObject::abs_impl(interpreter.vm(), interpreter.get(arguments.data()[0])));
LibJS: Call builtins directly in the bytecode interpreter Allows the bytecode interpreter to call the builtins c++ implementation directly without making a javascript call just as the JIT. Kraken test speedups: imaging-gaussian-blur.js (1.5x) and audio-oscillator.js (1.2x)
2023-11-30 19:49:29 +01:00
case Builtin::MathLog:
LibJS: Skip some hot bounds checks in the interpreter Let's allow ourselves to trust the number of property lookup caches present, along with a few other things.
2025-12-13 23:09:24 -06:00
return TRY(MathObject::log_impl(interpreter.vm(), interpreter.get(arguments.data()[0])));
LibJS/Bytecode: Put arguments directly in the Call instruction Instead of having Call refer to a range of VM registers, it now has a trailing list of argument operands as part of the instruction. This means we no longer have to shuffle every argument value into a register before making a call, making bytecode smaller & faster. :^)
2024-02-20 15:59:45 +01:00
case Builtin::MathPow:
LibJS: Skip some hot bounds checks in the interpreter Let's allow ourselves to trust the number of property lookup caches present, along with a few other things.
2025-12-13 23:09:24 -06:00
return TRY(MathObject::pow_impl(interpreter.vm(), interpreter.get(arguments.data()[0]), interpreter.get(arguments.data()[1])));
LibJS: Call builtins directly in the bytecode interpreter Allows the bytecode interpreter to call the builtins c++ implementation directly without making a javascript call just as the JIT. Kraken test speedups: imaging-gaussian-blur.js (1.5x) and audio-oscillator.js (1.2x)
2023-11-30 19:49:29 +01:00
case Builtin::MathExp:
LibJS: Skip some hot bounds checks in the interpreter Let's allow ourselves to trust the number of property lookup caches present, along with a few other things.
2025-12-13 23:09:24 -06:00
return TRY(MathObject::exp_impl(interpreter.vm(), interpreter.get(arguments.data()[0])));
LibJS: Call builtins directly in the bytecode interpreter Allows the bytecode interpreter to call the builtins c++ implementation directly without making a javascript call just as the JIT. Kraken test speedups: imaging-gaussian-blur.js (1.5x) and audio-oscillator.js (1.2x)
2023-11-30 19:49:29 +01:00
case Builtin::MathCeil:
LibJS: Skip some hot bounds checks in the interpreter Let's allow ourselves to trust the number of property lookup caches present, along with a few other things.
2025-12-13 23:09:24 -06:00
return TRY(MathObject::ceil_impl(interpreter.vm(), interpreter.get(arguments.data()[0])));
LibJS: Call builtins directly in the bytecode interpreter Allows the bytecode interpreter to call the builtins c++ implementation directly without making a javascript call just as the JIT. Kraken test speedups: imaging-gaussian-blur.js (1.5x) and audio-oscillator.js (1.2x)
2023-11-30 19:49:29 +01:00
case Builtin::MathFloor:
LibJS: Skip some hot bounds checks in the interpreter Let's allow ourselves to trust the number of property lookup caches present, along with a few other things.
2025-12-13 23:09:24 -06:00
return TRY(MathObject::floor_impl(interpreter.vm(), interpreter.get(arguments.data()[0])));
LibJS: Add builtin for Math.imul()
2025-04-03 11:58:30 +02:00
case Builtin::MathImul:
LibJS: Skip some hot bounds checks in the interpreter Let's allow ourselves to trust the number of property lookup caches present, along with a few other things.
2025-12-13 23:09:24 -06:00
return TRY(MathObject::imul_impl(interpreter.vm(), interpreter.get(arguments.data()[0]), interpreter.get(arguments.data()[1])));
LibJS: Add builtin for Math.random()
2025-04-03 12:01:31 +02:00
case Builtin::MathRandom:
return MathObject::random_impl();
LibJS: Call builtins directly in the bytecode interpreter Allows the bytecode interpreter to call the builtins c++ implementation directly without making a javascript call just as the JIT. Kraken test speedups: imaging-gaussian-blur.js (1.5x) and audio-oscillator.js (1.2x)
2023-11-30 19:49:29 +01:00
case Builtin::MathRound:
LibJS: Skip some hot bounds checks in the interpreter Let's allow ourselves to trust the number of property lookup caches present, along with a few other things.
2025-12-13 23:09:24 -06:00
return TRY(MathObject::round_impl(interpreter.vm(), interpreter.get(arguments.data()[0])));
LibJS: Call builtins directly in the bytecode interpreter Allows the bytecode interpreter to call the builtins c++ implementation directly without making a javascript call just as the JIT. Kraken test speedups: imaging-gaussian-blur.js (1.5x) and audio-oscillator.js (1.2x)
2023-11-30 19:49:29 +01:00
case Builtin::MathSqrt:
LibJS: Skip some hot bounds checks in the interpreter Let's allow ourselves to trust the number of property lookup caches present, along with a few other things.
2025-12-13 23:09:24 -06:00
return TRY(MathObject::sqrt_impl(interpreter.vm(), interpreter.get(arguments.data()[0])));
LibJS: Use CallBuiltin for Math.sin() Improves performance on https://pierre.co/
2025-05-26 13:54:46 +03:00
case Builtin::MathSin:
LibJS: Skip some hot bounds checks in the interpreter Let's allow ourselves to trust the number of property lookup caches present, along with a few other things.
2025-12-13 23:09:24 -06:00
return TRY(MathObject::sin_impl(interpreter.vm(), interpreter.get(arguments.data()[0])));
LibJS: Use CallBuiltin for Math.cos()
2025-05-26 14:03:37 +03:00
case Builtin::MathCos:
LibJS: Skip some hot bounds checks in the interpreter Let's allow ourselves to trust the number of property lookup caches present, along with a few other things.
2025-12-13 23:09:24 -06:00
return TRY(MathObject::cos_impl(interpreter.vm(), interpreter.get(arguments.data()[0])));
LibJS: Use CallBuiltin for Math.tan()
2025-05-26 14:07:59 +03:00
case Builtin::MathTan:
LibJS: Skip some hot bounds checks in the interpreter Let's allow ourselves to trust the number of property lookup caches present, along with a few other things.
2025-12-13 23:09:24 -06:00
return TRY(MathObject::tan_impl(interpreter.vm(), interpreter.get(arguments.data()[0])));
LibJS: Skip generic call when using regexp builtins in StringPrototype For StringPrototype functions that defer to RegExpPrototype builtins, we can skip the generic call stuff (eliding the execution context etc) and just call the builtin directly. 1.03x speedup on Octane/regexp.js
2025-12-13 09:47:52 -06:00
case Builtin::RegExpPrototypeExec:
case Builtin::RegExpPrototypeReplace:
case Builtin::RegExpPrototypeSplit:
LibJS: Do more comprehensive check if `next()` fast path is possible Before this change each built-in iterator object has a boolean `m_next_method_was_redefined`. If user code later changed the iterator’s prototype (e.g. `Object.setPrototypeOf()`), we still believed the built-in fast-path was safe and skipped the user supplied override, producing wrong results. With this change `BuiltinIterator::as_builtin_iterator_if_next_is_not_redefined()` looks up the current `next` property and verifies that it is still the built-in native function.
2025-06-01 18:44:18 +02:00
case Builtin::ArrayIteratorPrototypeNext:
case Builtin::MapIteratorPrototypeNext:
case Builtin::SetIteratorPrototypeNext:
case Builtin::StringIteratorPrototypeNext:
VERIFY_NOT_REACHED();
LibJS: Avoid function call if @@hasInstance is default implementation This makes the instanceof operator signficantly faster by avoiding a generic function call to @@hasInstance unless it has been overridden. 1.15x speed-up on Octane/earley-boyer.js
2025-10-13 12:21:59 +02:00
case Builtin::OrdinaryHasInstance:
VERIFY_NOT_REACHED();
LibJS: Call builtins directly in the bytecode interpreter Allows the bytecode interpreter to call the builtins c++ implementation directly without making a javascript call just as the JIT. Kraken test speedups: imaging-gaussian-blur.js (1.5x) and audio-oscillator.js (1.2x)
2023-11-30 19:49:29 +01:00
case Bytecode::Builtin::__Count:
VERIFY_NOT_REACHED();
}
VERIFY_NOT_REACHED();
}
Revert "LibJS: Allocate callee execution contexts in call instruction handler" This reverts commit cdcbbcf48b8a55ccfddc3f1cc036df931ac10c7e. It made MicroBench/call-*-args.js faster, but some of the macro benchmarks got significantly slower on macOS, so let's revert until we understand it better.
2025-11-01 12:51:36 +01:00
template<CallType call_type>
LibJS: Consolidate Put bytecode instructions and reduce code bloat Replace 20 separate Put instructions (5 PutKinds x 4 forms) with 4 unified instructions (PutById, PutByIdWithThis, PutByValue, PutByValueWithThis), each carrying a PutKind field at runtime instead of being a separate opcode. This reduces the number of handler entry points in the dispatch loop and eliminates template instantiations of put_by_property_key and put_by_value that were being duplicated 5x each when inlined by LTO.
2026-03-04 10:33:38 +01:00
NEVER_INLINE static ThrowCompletionOr<void> execute_call(
Revert "LibJS: Allocate callee execution contexts in call instruction handler" This reverts commit cdcbbcf48b8a55ccfddc3f1cc036df931ac10c7e. It made MicroBench/call-*-args.js faster, but some of the macro benchmarks got significantly slower on macOS, so let's revert until we understand it better.
2025-11-01 12:51:36 +01:00
Bytecode::Interpreter& interpreter,
Value callee,
Value this_value,
ReadonlySpan<Operand> arguments,
Operand dst,
LibJS: Pass Optional<T> const& by value more in the interpreter code
2025-12-04 10:02:11 +01:00
Optional<StringTableIndex> const expression_string,
Revert "LibJS: Allocate callee execution contexts in call instruction handler" This reverts commit cdcbbcf48b8a55ccfddc3f1cc036df931ac10c7e. It made MicroBench/call-*-args.js faster, but some of the macro benchmarks got significantly slower on macOS, so let's revert until we understand it better.
2025-11-01 12:51:36 +01:00
Strict strict)
{
TRY(throw_if_needed_for_call(interpreter, callee, call_type, expression_string));
LibJS+LibWeb: Use InterpreterStack for all execution context allocation Replace alloca-based execution context allocation with InterpreterStack bump allocation across all call sites: bytecode call instructions, AbstractOperations call/construct, script evaluation, module evaluation, and LibWeb module script evaluation. Also replace the native stack space check with an InterpreterStack exhaustion check, and remove the now-unused alloca macros from ExecutionContext.h.
2026-03-04 10:32:01 +01:00
auto& vm = interpreter.vm();
Revert "LibJS: Allocate callee execution contexts in call instruction handler" This reverts commit cdcbbcf48b8a55ccfddc3f1cc036df931ac10c7e. It made MicroBench/call-*-args.js faster, but some of the macro benchmarks got significantly slower on macOS, so let's revert until we understand it better.
2025-11-01 12:51:36 +01:00
auto& function = callee.as_function();
LibJS: Skip initializing constant slots in ExecutionContext Every function call allocates an ExecutionContext with a trailing array of Values for registers, locals, constants, and arguments. Previously, the constructor would initialize all slots to js_special_empty_value(), but constant slots were then immediately overwritten by the interpreter copying in values from the Executable before execution began. To eliminate this redundant initialization, we rearrange the layout from [registers | constants | locals] to [registers | locals | constants]. This groups registers and locals together at the front, allowing us to initialize only those slots while leaving constant slots uninitialized until they're populated with their actual values. This reduces the per-call initialization cost from O(registers + locals + constants) to O(registers + locals). Also tightens up the types involved (size_t -> u32) and adds VERIFYs to guard against overflow when computing the combined slot counts, and to ensure the total fits within the 29-bit operand index field.
2026-01-18 23:17:10 +01:00
size_t registers_and_locals_count = 0;
size_t constants_count = 0;
Revert "LibJS: Allocate callee execution contexts in call instruction handler" This reverts commit cdcbbcf48b8a55ccfddc3f1cc036df931ac10c7e. It made MicroBench/call-*-args.js faster, but some of the macro benchmarks got significantly slower on macOS, so let's revert until we understand it better.
2025-11-01 12:51:36 +01:00
size_t argument_count = arguments.size();
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
function.get_stack_frame_size(registers_and_locals_count, constants_count, argument_count);
LibJS+LibWeb: Use InterpreterStack for all execution context allocation Replace alloca-based execution context allocation with InterpreterStack bump allocation across all call sites: bytecode call instructions, AbstractOperations call/construct, script evaluation, module evaluation, and LibWeb module script evaluation. Also replace the native stack space check with an InterpreterStack exhaustion check, and remove the now-unused alloca macros from ExecutionContext.h.
2026-03-04 10:32:01 +01:00
auto& stack = vm.interpreter_stack();
auto* stack_mark = stack.top();
auto* callee_context = stack.allocate(registers_and_locals_count, constants_count, max(arguments.size(), argument_count));
if (!callee_context) [[unlikely]]
return vm.throw_completion<InternalError>(ErrorType::CallStackSizeExceeded);
ScopeGuard deallocate_guard = [&stack, stack_mark] { stack.deallocate(stack_mark); };
Revert "LibJS: Allocate callee execution contexts in call instruction handler" This reverts commit cdcbbcf48b8a55ccfddc3f1cc036df931ac10c7e. It made MicroBench/call-*-args.js faster, but some of the macro benchmarks got significantly slower on macOS, so let's revert until we understand it better.
2025-11-01 12:51:36 +01:00
auto* callee_context_argument_values = callee_context->arguments.data();
auto const callee_context_argument_count = callee_context->arguments.size();
auto const insn_argument_count = arguments.size();
for (size_t i = 0; i < insn_argument_count; ++i)
LibJS: Skip some hot bounds checks in the interpreter Let's allow ourselves to trust the number of property lookup caches present, along with a few other things.
2025-12-13 23:09:24 -06:00
callee_context_argument_values[i] = interpreter.get(arguments.data()[i]);
Revert "LibJS: Allocate callee execution contexts in call instruction handler" This reverts commit cdcbbcf48b8a55ccfddc3f1cc036df931ac10c7e. It made MicroBench/call-*-args.js faster, but some of the macro benchmarks got significantly slower on macOS, so let's revert until we understand it better.
2025-11-01 12:51:36 +01:00
for (size_t i = insn_argument_count; i < callee_context_argument_count; ++i)
callee_context_argument_values[i] = js_undefined();
callee_context->passed_argument_count = insn_argument_count;
Value retval;
if (call_type == CallType::DirectEval && callee == interpreter.realm().intrinsics().eval_function()) {
LibJS+LibWeb: Use InterpreterStack for all execution context allocation Replace alloca-based execution context allocation with InterpreterStack bump allocation across all call sites: bytecode call instructions, AbstractOperations call/construct, script evaluation, module evaluation, and LibWeb module script evaluation. Also replace the native stack space check with an InterpreterStack exhaustion check, and remove the now-unused alloca macros from ExecutionContext.h.
2026-03-04 10:32:01 +01:00
retval = TRY(perform_eval(vm, !callee_context->arguments.is_empty() ? callee_context->arguments[0] : js_undefined(), strict == Strict::Yes ? CallerMode::Strict : CallerMode::NonStrict, EvalMode::Direct));
Revert "LibJS: Allocate callee execution contexts in call instruction handler" This reverts commit cdcbbcf48b8a55ccfddc3f1cc036df931ac10c7e. It made MicroBench/call-*-args.js faster, but some of the macro benchmarks got significantly slower on macOS, so let's revert until we understand it better.
2025-11-01 12:51:36 +01:00
} else if (call_type == CallType::Construct) {
retval = TRY(function.internal_construct(*callee_context, function));
} else {
retval = TRY(function.internal_call(*callee_context, this_value));
}
interpreter.set(dst, retval);
LibJS: Split `Call` Instruction by `CallType` Instead of branching on the `CallType` at runtime in a hot instruction like `Call`, lets emit separate instructions for each call type during codegen.
2024-10-31 22:47:30 +01:00
return {};
Revert "LibJS: Allocate callee execution contexts in call instruction handler" This reverts commit cdcbbcf48b8a55ccfddc3f1cc036df931ac10c7e. It made MicroBench/call-*-args.js faster, but some of the macro benchmarks got significantly slower on macOS, so let's revert until we understand it better.
2025-11-01 12:51:36 +01:00
}
LibJS: Split `Call` Instruction by `CallType` Instead of branching on the `CallType` at runtime in a hot instruction like `Call`, lets emit separate instructions for each call type during codegen.
2024-10-31 22:47:30 +01:00
LibJS: Allocate Call{Construct,DirectEval,Builtin) contexts up front We already do this for normal Call contexts, so this is just continuing to propagate the same pattern to other instructions. Fixes #6026
2025-08-30 10:36:32 +02:00
ThrowCompletionOr<void> Call::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Split `Call` Instruction by `CallType` Instead of branching on the `CallType` at runtime in a hot instruction like `Call`, lets emit separate instructions for each call type during codegen.
2024-10-31 22:47:30 +01:00
{
Revert "LibJS: Allocate callee execution contexts in call instruction handler" This reverts commit cdcbbcf48b8a55ccfddc3f1cc036df931ac10c7e. It made MicroBench/call-*-args.js faster, but some of the macro benchmarks got significantly slower on macOS, so let's revert until we understand it better.
2025-11-01 12:51:36 +01:00
return execute_call<CallType::Call>(interpreter, interpreter.get(m_callee), interpreter.get(m_this_value), { m_arguments, m_argument_count }, m_dst, m_expression_string, strict());
LibJS: Allocate Call{Construct,DirectEval,Builtin) contexts up front We already do this for normal Call contexts, so this is just continuing to propagate the same pattern to other instructions. Fixes #6026
2025-08-30 10:36:32 +02:00
}
LibJS: Split `Call` Instruction by `CallType` Instead of branching on the `CallType` at runtime in a hot instruction like `Call`, lets emit separate instructions for each call type during codegen.
2024-10-31 22:47:30 +01:00
LibJS: Allocate Call{Construct,DirectEval,Builtin) contexts up front We already do this for normal Call contexts, so this is just continuing to propagate the same pattern to other instructions. Fixes #6026
2025-08-30 10:36:32 +02:00
NEVER_INLINE ThrowCompletionOr<void> CallConstruct::execute_impl(Bytecode::Interpreter& interpreter) const
{
Revert "LibJS: Allocate callee execution contexts in call instruction handler" This reverts commit cdcbbcf48b8a55ccfddc3f1cc036df931ac10c7e. It made MicroBench/call-*-args.js faster, but some of the macro benchmarks got significantly slower on macOS, so let's revert until we understand it better.
2025-11-01 12:51:36 +01:00
return execute_call<CallType::Construct>(interpreter, interpreter.get(m_callee), js_undefined(), { m_arguments, m_argument_count }, m_dst, m_expression_string, strict());
LibJS: Split `Call` Instruction by `CallType` Instead of branching on the `CallType` at runtime in a hot instruction like `Call`, lets emit separate instructions for each call type during codegen.
2024-10-31 22:47:30 +01:00
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> CallDirectEval::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Split `Call` Instruction by `CallType` Instead of branching on the `CallType` at runtime in a hot instruction like `Call`, lets emit separate instructions for each call type during codegen.
2024-10-31 22:47:30 +01:00
{
Revert "LibJS: Allocate callee execution contexts in call instruction handler" This reverts commit cdcbbcf48b8a55ccfddc3f1cc036df931ac10c7e. It made MicroBench/call-*-args.js faster, but some of the macro benchmarks got significantly slower on macOS, so let's revert until we understand it better.
2025-11-01 12:51:36 +01:00
return execute_call<CallType::DirectEval>(interpreter, interpreter.get(m_callee), interpreter.get(m_this_value), { m_arguments, m_argument_count }, m_dst, m_expression_string, strict());
LibJS: Split `Call` Instruction by `CallType` Instead of branching on the `CallType` at runtime in a hot instruction like `Call`, lets emit separate instructions for each call type during codegen.
2024-10-31 22:47:30 +01:00
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> CallBuiltin::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Split `Call` Instruction by `CallType` Instead of branching on the `CallType` at runtime in a hot instruction like `Call`, lets emit separate instructions for each call type during codegen.
2024-10-31 22:47:30 +01:00
{
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto callee = interpreter.get(m_callee);
LibJS: Split `Call` Instruction by `CallType` Instead of branching on the `CallType` at runtime in a hot instruction like `Call`, lets emit separate instructions for each call type during codegen.
2024-10-31 22:47:30 +01:00
LibJS: Simplify how we know which builtin a FunctionObject represents Instead of storing a list of builtin function objects with the realm, just move the builtin field from NativeFunction up to FunctionObject. Now you can ask any FunctionObject for its builtin(), and we no longer need the get_builtin_value() API. Fixes 10 test262 tests that were querying the realm builtins at a bad time. Regressed in 54b755126c8f369c0cbe7dcd143a8ebfe68d3330.
2025-12-25 19:52:43 +01:00
if (callee.is_function() && callee.as_function().builtin() == m_builtin) [[likely]] {
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(dst(), TRY(dispatch_builtin_call(interpreter, m_builtin, { m_arguments, m_argument_count })));
LibJS: Call builtins directly in the bytecode interpreter Allows the bytecode interpreter to call the builtins c++ implementation directly without making a javascript call just as the JIT. Kraken test speedups: imaging-gaussian-blur.js (1.5x) and audio-oscillator.js (1.2x)
2023-11-30 19:49:29 +01:00
return {};
}
Revert "LibJS: Allocate callee execution contexts in call instruction handler" This reverts commit cdcbbcf48b8a55ccfddc3f1cc036df931ac10c7e. It made MicroBench/call-*-args.js faster, but some of the macro benchmarks got significantly slower on macOS, so let's revert until we understand it better.
2025-11-01 12:51:36 +01:00
return execute_call<CallType::Call>(interpreter, callee, interpreter.get(m_this_value), { m_arguments, m_argument_count }, m_dst, m_expression_string, strict());
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
LibJS: Allocate context up front when calling with argument array This necessitated splitting CallWithArgumentArray into three variants, one for each call type (call, construct and direct eval).
2025-08-30 11:00:54 +02:00
template<CallType call_type>
LibJS: Consolidate Put bytecode instructions and reduce code bloat Replace 20 separate Put instructions (5 PutKinds x 4 forms) with 4 unified instructions (PutById, PutByIdWithThis, PutByValue, PutByValueWithThis), each carrying a PutKind field at runtime instead of being a separate opcode. This reduces the number of handler entry points in the dispatch loop and eliminates template instantiations of put_by_property_key and put_by_value that were being duplicated 5x each when inlined by LTO.
2026-03-04 10:33:38 +01:00
NEVER_INLINE static ThrowCompletionOr<void> call_with_argument_array(
LibJS: Allocate context up front when calling with argument array This necessitated splitting CallWithArgumentArray into three variants, one for each call type (call, construct and direct eval).
2025-08-30 11:00:54 +02:00
Bytecode::Interpreter& interpreter,
Value callee,
Value this_value,
Value arguments,
Operand dst,
LibJS: Pass Optional<T> const& by value more in the interpreter code
2025-12-04 10:02:11 +01:00
Optional<StringTableIndex> const expression_string,
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
Strict strict)
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
LibJS: Allocate context up front when calling with argument array This necessitated splitting CallWithArgumentArray into three variants, one for each call type (call, construct and direct eval).
2025-08-30 11:00:54 +02:00
TRY(throw_if_needed_for_call(interpreter, callee, call_type, expression_string));
LibJS+LibWeb: Use InterpreterStack for all execution context allocation Replace alloca-based execution context allocation with InterpreterStack bump allocation across all call sites: bytecode call instructions, AbstractOperations call/construct, script evaluation, module evaluation, and LibWeb module script evaluation. Also replace the native stack space check with an InterpreterStack exhaustion check, and remove the now-unused alloca macros from ExecutionContext.h.
2026-03-04 10:32:01 +01:00
auto& vm = interpreter.vm();
LibJS: Allocate context up front when calling with argument array This necessitated splitting CallWithArgumentArray into three variants, one for each call type (call, construct and direct eval).
2025-08-30 11:00:54 +02:00
auto& function = callee.as_function();
auto& argument_array = arguments.as_array();
auto argument_array_length = argument_array.indexed_properties().array_like_size();
size_t argument_count = argument_array_length;
LibJS: Skip initializing constant slots in ExecutionContext Every function call allocates an ExecutionContext with a trailing array of Values for registers, locals, constants, and arguments. Previously, the constructor would initialize all slots to js_special_empty_value(), but constant slots were then immediately overwritten by the interpreter copying in values from the Executable before execution began. To eliminate this redundant initialization, we rearrange the layout from [registers | constants | locals] to [registers | locals | constants]. This groups registers and locals together at the front, allowing us to initialize only those slots while leaving constant slots uninitialized until they're populated with their actual values. This reduces the per-call initialization cost from O(registers + locals + constants) to O(registers + locals). Also tightens up the types involved (size_t -> u32) and adds VERIFYs to guard against overflow when computing the combined slot counts, and to ensure the total fits within the 29-bit operand index field.
2026-01-18 23:17:10 +01:00
size_t registers_and_locals_count = 0;
size_t constants_count = 0;
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
function.get_stack_frame_size(registers_and_locals_count, constants_count, argument_count);
LibJS+LibWeb: Use InterpreterStack for all execution context allocation Replace alloca-based execution context allocation with InterpreterStack bump allocation across all call sites: bytecode call instructions, AbstractOperations call/construct, script evaluation, module evaluation, and LibWeb module script evaluation. Also replace the native stack space check with an InterpreterStack exhaustion check, and remove the now-unused alloca macros from ExecutionContext.h.
2026-03-04 10:32:01 +01:00
auto& stack = vm.interpreter_stack();
auto* stack_mark = stack.top();
auto* callee_context = stack.allocate(registers_and_locals_count, constants_count, max(argument_array_length, argument_count));
if (!callee_context) [[unlikely]]
return vm.throw_completion<InternalError>(ErrorType::CallStackSizeExceeded);
ScopeGuard deallocate_guard = [&stack, stack_mark] { stack.deallocate(stack_mark); };
LibJS: Allocate context up front when calling with argument array This necessitated splitting CallWithArgumentArray into three variants, one for each call type (call, construct and direct eval).
2025-08-30 11:00:54 +02:00
auto* callee_context_argument_values = callee_context->arguments.data();
auto const callee_context_argument_count = callee_context->arguments.size();
auto const insn_argument_count = argument_array_length;
for (size_t i = 0; i < insn_argument_count; ++i) {
if (auto maybe_value = argument_array.indexed_properties().get(i); maybe_value.has_value())
callee_context_argument_values[i] = maybe_value.release_value().value;
else
callee_context_argument_values[i] = js_undefined();
}
for (size_t i = insn_argument_count; i < callee_context_argument_count; ++i)
callee_context_argument_values[i] = js_undefined();
callee_context->passed_argument_count = insn_argument_count;
Value retval;
if (call_type == CallType::DirectEval && callee == interpreter.realm().intrinsics().eval_function()) {
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
retval = TRY(perform_eval(vm, !callee_context->arguments.is_empty() ? callee_context->arguments[0] : js_undefined(), strict == Strict::Yes ? CallerMode::Strict : CallerMode::NonStrict, EvalMode::Direct));
LibJS: Allocate context up front when calling with argument array This necessitated splitting CallWithArgumentArray into three variants, one for each call type (call, construct and direct eval).
2025-08-30 11:00:54 +02:00
} else if (call_type == CallType::Construct) {
retval = TRY(function.internal_construct(*callee_context, function));
} else {
retval = TRY(function.internal_call(*callee_context, this_value));
}
interpreter.set(dst, retval);
LibJS/Bytecode: Move perform_call helper to CommonImplementations
2023-10-20 13:20:28 +02:00
return {};
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
LibJS: Allocate context up front when calling with argument array This necessitated splitting CallWithArgumentArray into three variants, one for each call type (call, construct and direct eval).
2025-08-30 11:00:54 +02:00
ThrowCompletionOr<void> CallWithArgumentArray::execute_impl(Bytecode::Interpreter& interpreter) const
{
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
return call_with_argument_array<CallType::Call>(interpreter, interpreter.get(callee()), interpreter.get(this_value()), interpreter.get(arguments()), dst(), expression_string(), strict());
LibJS: Allocate context up front when calling with argument array This necessitated splitting CallWithArgumentArray into three variants, one for each call type (call, construct and direct eval).
2025-08-30 11:00:54 +02:00
}
ThrowCompletionOr<void> CallDirectEvalWithArgumentArray::execute_impl(Bytecode::Interpreter& interpreter) const
{
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
return call_with_argument_array<CallType::DirectEval>(interpreter, interpreter.get(callee()), interpreter.get(this_value()), interpreter.get(arguments()), dst(), expression_string(), strict());
LibJS: Allocate context up front when calling with argument array This necessitated splitting CallWithArgumentArray into three variants, one for each call type (call, construct and direct eval).
2025-08-30 11:00:54 +02:00
}
ThrowCompletionOr<void> CallConstructWithArgumentArray::execute_impl(Bytecode::Interpreter& interpreter) const
{
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
return call_with_argument_array<CallType::Construct>(interpreter, interpreter.get(callee()), js_undefined(), interpreter.get(arguments()), dst(), expression_string(), strict());
LibJS: Allocate context up front when calling with argument array This necessitated splitting CallWithArgumentArray into three variants, one for each call type (call, construct and direct eval).
2025-08-30 11:00:54 +02:00
}
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
// 13.3.7.1 Runtime Semantics: Evaluation, https://tc39.es/ecma262/#sec-super-keyword-runtime-semantics-evaluation
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> SuperCallWithArgumentArray::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
LibJS: Allocate context up front in SuperCallWithArgumentArray This also removes the last user of Interpreter's argument buffer allocation API, which we've used to repeatedly shoot ourselves in the foot. Good-bye!
2025-08-30 16:26:25 +02:00
auto& vm = interpreter.vm();
// 1. Let newTarget be GetNewTarget().
auto new_target = vm.get_new_target();
// 2. Assert: Type(newTarget) is Object.
VERIFY(new_target.is_object());
// 3. Let func be GetSuperConstructor().
auto* func = get_super_constructor(vm);
// NON-STANDARD: We're doing this step earlier to streamline control flow.
// 5. If IsConstructor(func) is false, throw a TypeError exception.
LibJS: Mark more error paths in the interpreter as [[unlikely]]
2025-12-04 10:35:26 +01:00
if (!Value(func).is_constructor()) [[unlikely]]
LibJS: Allocate context up front in SuperCallWithArgumentArray This also removes the last user of Interpreter's argument buffer allocation API, which we've used to repeatedly shoot ourselves in the foot. Good-bye!
2025-08-30 16:26:25 +02:00
return vm.throw_completion<TypeError>(ErrorType::NotAConstructor, "Super constructor");
auto& function = static_cast<FunctionObject&>(*func);
// 4. Let argList be ? ArgumentListEvaluation of Arguments.
auto& argument_array = interpreter.get(m_arguments).as_array();
size_t argument_array_length = 0;
if (m_is_synthetic) {
argument_array_length = MUST(length_of_array_like(vm, argument_array));
} else {
argument_array_length = argument_array.indexed_properties().array_like_size();
}
size_t argument_count = argument_array_length;
LibJS: Skip initializing constant slots in ExecutionContext Every function call allocates an ExecutionContext with a trailing array of Values for registers, locals, constants, and arguments. Previously, the constructor would initialize all slots to js_special_empty_value(), but constant slots were then immediately overwritten by the interpreter copying in values from the Executable before execution began. To eliminate this redundant initialization, we rearrange the layout from [registers | constants | locals] to [registers | locals | constants]. This groups registers and locals together at the front, allowing us to initialize only those slots while leaving constant slots uninitialized until they're populated with their actual values. This reduces the per-call initialization cost from O(registers + locals + constants) to O(registers + locals). Also tightens up the types involved (size_t -> u32) and adds VERIFYs to guard against overflow when computing the combined slot counts, and to ensure the total fits within the 29-bit operand index field.
2026-01-18 23:17:10 +01:00
size_t registers_and_locals_count = 0;
size_t constants_count = 0;
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
function.get_stack_frame_size(registers_and_locals_count, constants_count, argument_count);
LibJS+LibWeb: Use InterpreterStack for all execution context allocation Replace alloca-based execution context allocation with InterpreterStack bump allocation across all call sites: bytecode call instructions, AbstractOperations call/construct, script evaluation, module evaluation, and LibWeb module script evaluation. Also replace the native stack space check with an InterpreterStack exhaustion check, and remove the now-unused alloca macros from ExecutionContext.h.
2026-03-04 10:32:01 +01:00
auto& stack = vm.interpreter_stack();
auto* stack_mark = stack.top();
auto* callee_context = stack.allocate(registers_and_locals_count, constants_count, max(argument_array_length, argument_count));
if (!callee_context) [[unlikely]]
return vm.throw_completion<InternalError>(ErrorType::CallStackSizeExceeded);
ScopeGuard deallocate_guard = [&stack, stack_mark] { stack.deallocate(stack_mark); };
LibJS: Allocate context up front in SuperCallWithArgumentArray This also removes the last user of Interpreter's argument buffer allocation API, which we've used to repeatedly shoot ourselves in the foot. Good-bye!
2025-08-30 16:26:25 +02:00
auto* callee_context_argument_values = callee_context->arguments.data();
auto const callee_context_argument_count = callee_context->arguments.size();
auto const insn_argument_count = argument_array_length;
if (m_is_synthetic) {
for (size_t i = 0; i < insn_argument_count; ++i)
callee_context_argument_values[i] = argument_array.get_without_side_effects(PropertyKey { i });
} else {
for (size_t i = 0; i < insn_argument_count; ++i) {
if (auto maybe_value = argument_array.indexed_properties().get(i); maybe_value.has_value())
callee_context_argument_values[i] = maybe_value.release_value().value;
else
callee_context_argument_values[i] = js_undefined();
}
}
for (size_t i = insn_argument_count; i < callee_context_argument_count; ++i)
callee_context_argument_values[i] = js_undefined();
callee_context->passed_argument_count = insn_argument_count;
// 6. Let result be ? Construct(func, argList, newTarget).
auto result = TRY(function.internal_construct(*callee_context, new_target.as_function()));
// 7. Let thisER be GetThisEnvironment().
auto& this_environment = as<FunctionEnvironment>(*get_this_environment(vm));
// 8. Perform ? thisER.BindThisValue(result).
TRY(this_environment.bind_this_value(vm, result));
// 9. Let F be thisER.[[FunctionObject]].
LibJS: Introduce NativeJavaScriptBackedFunction This hosts the ability to compile and run JavaScript to implement native functions. This is particularly useful for any native function that is not a normal function, for example async functions such as Array.fromAsync, which require yielding. These functions are not allowed to observe anything from outside their environment. Any global identifiers will instead be assumed to be a reference to an abstract operation or a constant. The generator will inject the appropriate bytecode if the name of the global identifier matches a known name. Anything else will cause a code generation error.
2025-11-06 19:00:36 +00:00
auto& f = as<ECMAScriptFunctionObject>(this_environment.function_object());
LibJS: Allocate context up front in SuperCallWithArgumentArray This also removes the last user of Interpreter's argument buffer allocation API, which we've used to repeatedly shoot ourselves in the foot. Good-bye!
2025-08-30 16:26:25 +02:00
// 10. Assert: F is an ECMAScript function object.
// NOTE: This is implied by the strong C++ type.
// 11. Perform ? InitializeInstanceElements(result, F).
TRY(result->initialize_instance_elements(f));
// 12. Return result.
interpreter.set(m_dst, result);
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
void NewFunction::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
LibJS: Pre-create SharedFunctionInstanceData in NewFunction Replace the FunctionNode const& stored on the NewFunction bytecode instruction with an index into a table of pre-created SharedFunctionInstanceData objects on the Executable. During bytecode compilation, we now eagerly create SharedFunctionInstanceData for each function that will be instantiated by NewFunction, and store it on both the FunctionNode (for caching) and the Executable (for GC tracing). At runtime, NewFunction simply looks up the SharedFunctionInstanceData by index and calls create_from_function_data() directly, bypassing the AST entirely. This removes one of the main reasons the AST had to stay alive after compilation. The instantiate_ordinary_function_expression() helper in Interpreter.cpp is removed as its non-trivial code path (creating a scope for named function expressions) was dead code -- it was only called when !has_name(), so the has_own_name branch never executed.
2026-02-10 23:02:46 +01:00
interpreter.set(dst(), new_function(interpreter, m_shared_function_data_index, m_home_object));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
void Return::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
LibJS: Make Op::Return value required It turns out we do not have any scenario where this is not provided.
2025-05-16 12:28:51 +12:00
interpreter.do_return(interpreter.get(m_value));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> Increment::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
auto& vm = interpreter.vm();
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto old_value = interpreter.get(dst());
LibJS: Fast path for Increment of Int32 value in bytecode interpreter 5% speed-up on Kraken/ai-astar.js in interpreter mode. :^)
2024-01-27 20:51:11 +01:00
// OPTIMIZATION: Fast path for Int32 values.
LibJS: Mark Int32 paths in Increment and PostfixIncrement [[likely]]
2025-12-04 21:26:58 +01:00
if (old_value.is_int32()) [[likely]] {
LibJS: Fast path for Increment of Int32 value in bytecode interpreter 5% speed-up on Kraken/ai-astar.js in interpreter mode. :^)
2024-01-27 20:51:11 +01:00
auto integer_value = old_value.as_i32();
if (integer_value != NumericLimits<i32>::max()) [[likely]] {
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(dst(), Value { integer_value + 1 });
LibJS: Fast path for Increment of Int32 value in bytecode interpreter 5% speed-up on Kraken/ai-astar.js in interpreter mode. :^)
2024-01-27 20:51:11 +01:00
return {};
}
}
old_value = TRY(old_value.to_numeric(vm));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
if (old_value.is_number())
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(dst(), Value(old_value.as_double() + 1));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
else
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(dst(), BigInt::create(vm, old_value.as_bigint().big_integer().plus(Crypto::SignedBigInteger { 1 })));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> PostfixIncrement::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS/Bytecode: Dedicated instructions for postfix increment/decrement Instead of splitting the postfix variants into ToNumeric + Inc/Dec, we now have dedicated PostfixIncrement and PostfixDecrement instructions that handle both outputs in one go.
2024-02-20 11:45:01 +01:00
{
auto& vm = interpreter.vm();
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto old_value = interpreter.get(m_src);
LibJS/Bytecode: Dedicated instructions for postfix increment/decrement Instead of splitting the postfix variants into ToNumeric + Inc/Dec, we now have dedicated PostfixIncrement and PostfixDecrement instructions that handle both outputs in one go.
2024-02-20 11:45:01 +01:00
// OPTIMIZATION: Fast path for Int32 values.
LibJS: Mark Int32 paths in Increment and PostfixIncrement [[likely]]
2025-12-04 21:26:58 +01:00
if (old_value.is_int32()) [[likely]] {
LibJS/Bytecode: Dedicated instructions for postfix increment/decrement Instead of splitting the postfix variants into ToNumeric + Inc/Dec, we now have dedicated PostfixIncrement and PostfixDecrement instructions that handle both outputs in one go.
2024-02-20 11:45:01 +01:00
auto integer_value = old_value.as_i32();
if (integer_value != NumericLimits<i32>::max()) [[likely]] {
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, old_value);
interpreter.set(m_src, Value { integer_value + 1 });
LibJS/Bytecode: Dedicated instructions for postfix increment/decrement Instead of splitting the postfix variants into ToNumeric + Inc/Dec, we now have dedicated PostfixIncrement and PostfixDecrement instructions that handle both outputs in one go.
2024-02-20 11:45:01 +01:00
return {};
}
}
old_value = TRY(old_value.to_numeric(vm));
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, old_value);
LibJS/Bytecode: Dedicated instructions for postfix increment/decrement Instead of splitting the postfix variants into ToNumeric + Inc/Dec, we now have dedicated PostfixIncrement and PostfixDecrement instructions that handle both outputs in one go.
2024-02-20 11:45:01 +01:00
if (old_value.is_number())
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_src, Value(old_value.as_double() + 1));
LibJS/Bytecode: Dedicated instructions for postfix increment/decrement Instead of splitting the postfix variants into ToNumeric + Inc/Dec, we now have dedicated PostfixIncrement and PostfixDecrement instructions that handle both outputs in one go.
2024-02-20 11:45:01 +01:00
else
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_src, BigInt::create(vm, old_value.as_bigint().big_integer().plus(Crypto::SignedBigInteger { 1 })));
LibJS/Bytecode: Dedicated instructions for postfix increment/decrement Instead of splitting the postfix variants into ToNumeric + Inc/Dec, we now have dedicated PostfixIncrement and PostfixDecrement instructions that handle both outputs in one go.
2024-02-20 11:45:01 +01:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> Decrement::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
auto& vm = interpreter.vm();
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto old_value = interpreter.get(dst());
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
old_value = TRY(old_value.to_numeric(vm));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
if (old_value.is_number())
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(dst(), Value(old_value.as_double() - 1));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
else
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(dst(), BigInt::create(vm, old_value.as_bigint().big_integer().minus(Crypto::SignedBigInteger { 1 })));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> PostfixDecrement::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS/Bytecode: Dedicated instructions for postfix increment/decrement Instead of splitting the postfix variants into ToNumeric + Inc/Dec, we now have dedicated PostfixIncrement and PostfixDecrement instructions that handle both outputs in one go.
2024-02-20 11:45:01 +01:00
{
auto& vm = interpreter.vm();
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto old_value = interpreter.get(m_src);
LibJS/Bytecode: Dedicated instructions for postfix increment/decrement Instead of splitting the postfix variants into ToNumeric + Inc/Dec, we now have dedicated PostfixIncrement and PostfixDecrement instructions that handle both outputs in one go.
2024-02-20 11:45:01 +01:00
old_value = TRY(old_value.to_numeric(vm));
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_dst, old_value);
LibJS/Bytecode: Dedicated instructions for postfix increment/decrement Instead of splitting the postfix variants into ToNumeric + Inc/Dec, we now have dedicated PostfixIncrement and PostfixDecrement instructions that handle both outputs in one go.
2024-02-20 11:45:01 +01:00
if (old_value.is_number())
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_src, Value(old_value.as_double() - 1));
LibJS/Bytecode: Dedicated instructions for postfix increment/decrement Instead of splitting the postfix variants into ToNumeric + Inc/Dec, we now have dedicated PostfixIncrement and PostfixDecrement instructions that handle both outputs in one go.
2024-02-20 11:45:01 +01:00
else
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(m_src, BigInt::create(vm, old_value.as_bigint().big_integer().minus(Crypto::SignedBigInteger { 1 })));
LibJS/Bytecode: Dedicated instructions for postfix increment/decrement Instead of splitting the postfix variants into ToNumeric + Inc/Dec, we now have dedicated PostfixIncrement and PostfixDecrement instructions that handle both outputs in one go.
2024-02-20 11:45:01 +01:00
return {};
}
LibJS: Mark three uncommon instruction handlers COLD - with statement - throw statement - catch statement All of these should be rare cases (especially with!)
2025-12-09 17:39:00 -06:00
COLD ThrowCompletionOr<void> Throw::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
return throw_completion(interpreter.get(src()));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> ThrowIfNotObject::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
auto& vm = interpreter.vm();
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto src = interpreter.get(m_src);
LibJS: Mark some throwing paths in interpreter as [[unlikely]]
2025-12-04 10:15:59 +01:00
if (!src.is_object()) [[unlikely]]
LibJS: Pass JS::Value directly to string formatting functions We don't need to call .to_string_without_side_effects() when passing a JS::Value in for string formatting. The Formatter will do it for us.
2025-12-05 08:01:44 +01:00
return vm.throw_completion<TypeError>(ErrorType::NotAnObject, src);
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> ThrowIfNullish::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
auto& vm = interpreter.vm();
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto value = interpreter.get(m_src);
LibJS: Mark some throwing paths in interpreter as [[unlikely]]
2025-12-04 10:15:59 +01:00
if (value.is_nullish()) [[unlikely]]
LibJS: Pass JS::Value directly to string formatting functions We don't need to call .to_string_without_side_effects() when passing a JS::Value in for string formatting. The Formatter will do it for us.
2025-12-05 08:01:44 +01:00
return vm.throw_completion<TypeError>(ErrorType::NotObjectCoercible, value);
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> ThrowIfTDZ::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
{
auto& vm = interpreter.vm();
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto value = interpreter.get(m_src);
LibJS: Mark some throwing paths in interpreter as [[unlikely]]
2025-12-04 10:15:59 +01:00
if (value.is_special_empty_value()) [[unlikely]]
LibJS: Pass JS::Value directly to string formatting functions We don't need to call .to_string_without_side_effects() when passing a JS::Value in for string formatting. The Formatter will do it for us.
2025-12-05 08:01:44 +01:00
return vm.throw_completion<ReferenceError>(ErrorType::BindingNotInitialized, value);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return {};
}
LibJS: Do not allow reassignment to local const variable
2026-02-09 20:27:31 +01:00
ThrowCompletionOr<void> ThrowConstAssignment::execute_impl(Bytecode::Interpreter& interpreter) const
{
auto& vm = interpreter.vm();
return vm.throw_completion<TypeError>(ErrorType::InvalidAssignToConst);
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
void LeavePrivateEnvironment::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Stop using execute_ast_node() for class property evaluation Instead, generate bytecode to execute their AST nodes and save the resulting operands inside the NewClass instruction. Moving property expression evaluation to happen before NewClass execution also moves along creation of new private environment and its population with private members (private members should be visible during property evaluation). Before: - NewClass After: - CreatePrivateEnvironment - AddPrivateName - ... - AddPrivateName - NewClass - LeavePrivateEnvironment
2024-05-11 22:54:41 +00:00
{
auto& running_execution_context = interpreter.vm().running_execution_context();
running_execution_context.private_environment = running_execution_context.private_environment->outer_environment();
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
void Yield::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto yielded_value = interpreter.get(m_value).is_special_empty_value() ? js_undefined() : interpreter.get(m_value);
LibJS: Prepare yield object before re-routing it through finally
2024-05-18 17:25:43 +02:00
interpreter.do_return(
interpreter.do_yield(yielded_value, m_continuation_label));
}
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
void Await::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto yielded_value = interpreter.get(m_argument).is_special_empty_value() ? js_undefined() : interpreter.get(m_argument);
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
// FIXME: If we get a pointer, which is not accurately representable as a double
// will cause this to explode
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
auto continuation_value = Value(m_continuation_label.address());
auto result = interpreter.vm().heap().allocate<GeneratorResult>(yielded_value, continuation_value, true);
interpreter.do_return(result);
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> GetByValue::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(dst(), TRY(get_by_value(interpreter.vm(), m_base_identifier, interpreter.get(m_base), interpreter.get(m_property), interpreter.current_executable())));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> GetByValueWithThis::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
auto& vm = interpreter.vm();
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto property_key_value = interpreter.get(m_property);
auto object = TRY(interpreter.get(m_base).to_object(vm));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
auto property_key = TRY(property_key_value.to_property_key(vm));
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(dst(), TRY(object->internal_get(property_key, interpreter.get(m_this_value))));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return {};
}
LibJS: Consolidate Put bytecode instructions and reduce code bloat Replace 20 separate Put instructions (5 PutKinds x 4 forms) with 4 unified instructions (PutById, PutByIdWithThis, PutByValue, PutByValueWithThis), each carrying a PutKind field at runtime instead of being a separate opcode. This reduces the number of handler entry points in the dispatch loop and eliminates template instantiations of put_by_property_key and put_by_value that were being duplicated 5x each when inlined by LTO.
2026-03-04 10:33:38 +01:00
ThrowCompletionOr<void> PutByValue::execute_impl(Bytecode::Interpreter& interpreter) const
{
auto& vm = interpreter.vm();
auto value = interpreter.get(m_src);
auto base = interpreter.get(m_base);
auto const& base_identifier = interpreter.get_identifier(m_base_identifier);
auto property = interpreter.get(m_property);
TRY(put_by_value(vm, base, base_identifier, property, value, m_kind, strict()));
return {};
}
LibJS: Split PutBy* instructions into specialized per-kind variants This allows the compiler to fold away lots of unused code for each kind. 1.10x speed-up on MicroBench/pic-add-own.js :^)
2025-10-10 12:09:34 +02:00
LibJS: Consolidate Put bytecode instructions and reduce code bloat Replace 20 separate Put instructions (5 PutKinds x 4 forms) with 4 unified instructions (PutById, PutByIdWithThis, PutByValue, PutByValueWithThis), each carrying a PutKind field at runtime instead of being a separate opcode. This reduces the number of handler entry points in the dispatch loop and eliminates template instantiations of put_by_property_key and put_by_value that were being duplicated 5x each when inlined by LTO.
2026-03-04 10:33:38 +01:00
ThrowCompletionOr<void> PutByValueWithThis::execute_impl(Bytecode::Interpreter& interpreter) const
{
auto& vm = interpreter.vm();
auto value = interpreter.get(m_src);
auto base = interpreter.get(m_base);
auto this_value = interpreter.get(m_this_value);
auto property_key = TRY(interpreter.get(m_property).to_property_key(vm));
TRY(put_by_property_key(vm, base, this_value, value, {}, property_key, m_kind, strict()));
return {};
}
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
LibJS: Mark `delete` operator instruction handlers COLD The delete operator is very rarely used in JavaScript, so let's keep it off the hot path.
2025-12-10 06:37:06 -06:00
COLD ThrowCompletionOr<void> DeleteByValue::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
auto& vm = interpreter.vm();
auto property_key = TRY(interpreter.get(m_property).to_property_key(vm));
auto reference = Reference { interpreter.get(m_base), property_key, {}, strict() };
interpreter.set(m_dst, Value(TRY(reference.delete_(vm))));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> GetIterator::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
auto& vm = interpreter.vm();
LibJS: Avoid `IteratorRecord` GC-allocation in `GetIterator` instruction With this change, `GetIterator` no longer GC-allocates an `IteratorRecord`. Instead, it stores the iterator record fields in bytecode registers. This avoids per-iteration allocations in patterns like: `for (let [x] of array) {}`. `IteratorRecord` now inherits from `IteratorRecordImpl`, which holds the iteration state. This allows the existing iteration helpers (`iterator_next()`, `iterator_step()`, etc.) operate on both the GC-allocated and the register-backed forms. Microbenchmarks: 1.1x array-destructuring-assignment-rest.js 1.226x array-destructuring-assignment.js
2025-10-27 19:46:54 +01:00
auto iterator_record = TRY(get_iterator_impl(vm, interpreter.get(iterable()), m_hint));
interpreter.set(m_dst_iterator_object, iterator_record.iterator);
interpreter.set(m_dst_iterator_next, iterator_record.next_method);
interpreter.set(m_dst_iterator_done, Value(iterator_record.done));
LibJS: Stop converting between Object <-> IteratorRecord all the time 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);
2023-12-07 10:44:41 +01:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> GetMethod::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
auto& vm = interpreter.vm();
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
auto const& property_key = interpreter.get_property_key(m_property);
auto method = TRY(interpreter.get(m_object).get_method(vm, property_key));
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(dst(), method ?: js_undefined());
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return {};
}
LibJS: Mark GetObjectPropertyIterator and NewClass NEVER_INLINE These instructions are not necessarily rarely used, but they are very large in terms of code size. By putting them out of line we keep the hot path of the interpreter smaller and tighter.
2025-12-10 06:40:41 -06:00
NEVER_INLINE ThrowCompletionOr<void> GetObjectPropertyIterator::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
LibJS: Avoid `IteratorRecord` GC-allocation in `GetIterator` instruction With this change, `GetIterator` no longer GC-allocates an `IteratorRecord`. Instead, it stores the iterator record fields in bytecode registers. This avoids per-iteration allocations in patterns like: `for (let [x] of array) {}`. `IteratorRecord` now inherits from `IteratorRecordImpl`, which holds the iteration state. This allows the existing iteration helpers (`iterator_next()`, `iterator_step()`, etc.) operate on both the GC-allocated and the register-backed forms. Microbenchmarks: 1.1x array-destructuring-assignment-rest.js 1.226x array-destructuring-assignment.js
2025-10-27 19:46:54 +01:00
auto iterator_record = TRY(get_object_property_iterator(interpreter, interpreter.get(m_object)));
interpreter.set(m_dst_iterator_object, iterator_record.iterator);
interpreter.set(m_dst_iterator_next, iterator_record.next_method);
interpreter.set(m_dst_iterator_done, Value(iterator_record.done));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> IteratorClose::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
auto& vm = interpreter.vm();
LibJS: Avoid `IteratorRecord` GC-allocation in `GetIterator` instruction With this change, `GetIterator` no longer GC-allocates an `IteratorRecord`. Instead, it stores the iterator record fields in bytecode registers. This avoids per-iteration allocations in patterns like: `for (let [x] of array) {}`. `IteratorRecord` now inherits from `IteratorRecordImpl`, which holds the iteration state. This allows the existing iteration helpers (`iterator_next()`, `iterator_step()`, etc.) operate on both the GC-allocated and the register-backed forms. Microbenchmarks: 1.1x array-destructuring-assignment-rest.js 1.226x array-destructuring-assignment.js
2025-10-27 19:46:54 +01:00
auto& iterator_object = interpreter.get(m_iterator_object).as_object();
auto iterator_next_method = interpreter.get(m_iterator_next);
auto iterator_done_property = interpreter.get(m_iterator_done).as_bool();
IteratorRecordImpl iterator_record { .done = iterator_done_property, .iterator = iterator_object, .next_method = iterator_next_method };
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
LibJS: Make IteratorClose/AsyncIteratorClose take Operand for value Change the completion_value field from Optional<Value> to Operand in both IteratorClose and AsyncIteratorClose bytecode instructions. This allows passing a dynamic value from a register, which is needed for iterator close on abrupt completion where the exception value is not known at codegen time.
2026-02-11 23:49:20 +01:00
// FIXME: Return the value of the resulting completion.
TRY(iterator_close(vm, iterator_record, Completion { m_completion_type, interpreter.get(m_completion_value) }));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> IteratorNext::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
auto& vm = interpreter.vm();
LibJS: Avoid `IteratorRecord` GC-allocation in `GetIterator` instruction With this change, `GetIterator` no longer GC-allocates an `IteratorRecord`. Instead, it stores the iterator record fields in bytecode registers. This avoids per-iteration allocations in patterns like: `for (let [x] of array) {}`. `IteratorRecord` now inherits from `IteratorRecordImpl`, which holds the iteration state. This allows the existing iteration helpers (`iterator_next()`, `iterator_step()`, etc.) operate on both the GC-allocated and the register-backed forms. Microbenchmarks: 1.1x array-destructuring-assignment-rest.js 1.226x array-destructuring-assignment.js
2025-10-27 19:46:54 +01:00
auto& iterator_object = interpreter.get(m_iterator_object).as_object();
auto iterator_next_method = interpreter.get(m_iterator_next);
auto iterator_done_property = interpreter.get(m_iterator_done).as_bool();
IteratorRecordImpl iterator_record { .done = iterator_done_property, .iterator = iterator_object, .next_method = iterator_next_method };
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
interpreter.set(m_dst, TRY(JS::iterator_next(vm, iterator_record)));
LibJS: Avoid `IteratorRecord` GC-allocation in `GetIterator` instruction With this change, `GetIterator` no longer GC-allocates an `IteratorRecord`. Instead, it stores the iterator record fields in bytecode registers. This avoids per-iteration allocations in patterns like: `for (let [x] of array) {}`. `IteratorRecord` now inherits from `IteratorRecordImpl`, which holds the iteration state. This allows the existing iteration helpers (`iterator_next()`, `iterator_step()`, etc.) operate on both the GC-allocated and the register-backed forms. Microbenchmarks: 1.1x array-destructuring-assignment-rest.js 1.226x array-destructuring-assignment.js
2025-10-27 19:46:54 +01:00
if (iterator_done_property)
interpreter.set(m_iterator_done, Value(true));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return {};
}
LibJS: Optimize array destructuring assignment for builtin iterators ...by avoiding `{ value, done }` iterator result value allocation. This change applies the same otimization 81b6a11 added for `for..in` and `for..of`. Makes following micro benchmark go 22% faster on my computer: ```js function f() { const arr = []; for (let i = 0; i < 10_000_000; i++) { arr.push([i]); } let sum = 0; for (let [i] of arr) { sum += i; } } f(); ```
2025-05-01 16:05:24 +03:00
ThrowCompletionOr<void> IteratorNextUnpack::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Skip iterator result object allocation in for..of and for..in Introduce special instruction for `for..of` and `for..in` loop that skips `{ value, done }` result object allocation if iterator is builtin (array, map, set, string). This reduces GC pressure significantly and avoids extracting the `value` and `done` properties. This change makes this micro benchmark 48% faster on my computer: ```js const arr = new Array(10_000_000); let counter = 0; for (let _ of arr) { counter++; } ```
2025-04-30 16:31:26 +03:00
{
auto& vm = interpreter.vm();
LibJS: Avoid `IteratorRecord` GC-allocation in `GetIterator` instruction With this change, `GetIterator` no longer GC-allocates an `IteratorRecord`. Instead, it stores the iterator record fields in bytecode registers. This avoids per-iteration allocations in patterns like: `for (let [x] of array) {}`. `IteratorRecord` now inherits from `IteratorRecordImpl`, which holds the iteration state. This allows the existing iteration helpers (`iterator_next()`, `iterator_step()`, etc.) operate on both the GC-allocated and the register-backed forms. Microbenchmarks: 1.1x array-destructuring-assignment-rest.js 1.226x array-destructuring-assignment.js
2025-10-27 19:46:54 +01:00
auto& iterator_object = interpreter.get(m_iterator_object).as_object();
auto iterator_next_method = interpreter.get(m_iterator_next);
auto iterator_done_property = interpreter.get(m_iterator_done).as_bool();
IteratorRecordImpl iterator_record { .done = iterator_done_property, .iterator = iterator_object, .next_method = iterator_next_method };
LibJS: Use `iteration_step()` in IteratorNextUnpack instruction Allows us to avoid code duplication for builtin iterators fast path.
2025-05-12 17:32:54 +03:00
auto iteration_result_or_done = TRY(iterator_step(vm, iterator_record));
LibJS: Avoid `IteratorRecord` GC-allocation in `GetIterator` instruction With this change, `GetIterator` no longer GC-allocates an `IteratorRecord`. Instead, it stores the iterator record fields in bytecode registers. This avoids per-iteration allocations in patterns like: `for (let [x] of array) {}`. `IteratorRecord` now inherits from `IteratorRecordImpl`, which holds the iteration state. This allows the existing iteration helpers (`iterator_next()`, `iterator_step()`, etc.) operate on both the GC-allocated and the register-backed forms. Microbenchmarks: 1.1x array-destructuring-assignment-rest.js 1.226x array-destructuring-assignment.js
2025-10-27 19:46:54 +01:00
if (iterator_done_property)
interpreter.set(m_iterator_done, Value(true));
LibJS: Use `iteration_step()` in IteratorNextUnpack instruction Allows us to avoid code duplication for builtin iterators fast path.
2025-05-12 17:32:54 +03:00
if (iteration_result_or_done.has<IterationDone>()) {
LibJS: Avoid `IteratorRecord` GC-allocation in `GetIterator` instruction With this change, `GetIterator` no longer GC-allocates an `IteratorRecord`. Instead, it stores the iterator record fields in bytecode registers. This avoids per-iteration allocations in patterns like: `for (let [x] of array) {}`. `IteratorRecord` now inherits from `IteratorRecordImpl`, which holds the iteration state. This allows the existing iteration helpers (`iterator_next()`, `iterator_step()`, etc.) operate on both the GC-allocated and the register-backed forms. Microbenchmarks: 1.1x array-destructuring-assignment-rest.js 1.226x array-destructuring-assignment.js
2025-10-27 19:46:54 +01:00
interpreter.set(m_dst_done, Value(true));
LibJS: Use `iteration_step()` in IteratorNextUnpack instruction Allows us to avoid code duplication for builtin iterators fast path.
2025-05-12 17:32:54 +03:00
return {};
LibJS: Skip iterator result object allocation in for..of and for..in Introduce special instruction for `for..of` and `for..in` loop that skips `{ value, done }` result object allocation if iterator is builtin (array, map, set, string). This reduces GC pressure significantly and avoids extracting the `value` and `done` properties. This change makes this micro benchmark 48% faster on my computer: ```js const arr = new Array(10_000_000); let counter = 0; for (let _ of arr) { counter++; } ```
2025-04-30 16:31:26 +03:00
}
LibJS: Use `iteration_step()` in IteratorNextUnpack instruction Allows us to avoid code duplication for builtin iterators fast path.
2025-05-12 17:32:54 +03:00
auto& iteration_result = iteration_result_or_done.get<IterationResult>();
LibJS: Avoid `IteratorRecord` GC-allocation in `GetIterator` instruction With this change, `GetIterator` no longer GC-allocates an `IteratorRecord`. Instead, it stores the iterator record fields in bytecode registers. This avoids per-iteration allocations in patterns like: `for (let [x] of array) {}`. `IteratorRecord` now inherits from `IteratorRecordImpl`, which holds the iteration state. This allows the existing iteration helpers (`iterator_next()`, `iterator_step()`, etc.) operate on both the GC-allocated and the register-backed forms. Microbenchmarks: 1.1x array-destructuring-assignment-rest.js 1.226x array-destructuring-assignment.js
2025-10-27 19:46:54 +01:00
interpreter.set(m_dst_done, TRY(iteration_result.done));
interpreter.set(m_dst_value, TRY(iteration_result.value));
LibJS: Skip iterator result object allocation in for..of and for..in Introduce special instruction for `for..of` and `for..in` loop that skips `{ value, done }` result object allocation if iterator is builtin (array, map, set, string). This reduces GC pressure significantly and avoids extracting the `value` and `done` properties. This change makes this micro benchmark 48% faster on my computer: ```js const arr = new Array(10_000_000); let counter = 0; for (let _ of arr) { counter++; } ```
2025-04-30 16:31:26 +03:00
return {};
}
LibJS: Mark GetObjectPropertyIterator and NewClass NEVER_INLINE These instructions are not necessarily rarely used, but they are very large in terms of code size. By putting them out of line we keep the hot path of the interpreter smaller and tighter.
2025-12-10 06:40:41 -06:00
NEVER_INLINE ThrowCompletionOr<void> NewClass::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
Value super_class;
if (m_super_class.has_value())
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
super_class = interpreter.get(m_super_class.value());
LibJS: Stop using execute_ast_node() for class property evaluation Instead, generate bytecode to execute their AST nodes and save the resulting operands inside the NewClass instruction. Moving property expression evaluation to happen before NewClass execution also moves along creation of new private environment and its population with private members (private members should be visible during property evaluation). Before: - NewClass After: - CreatePrivateEnvironment - AddPrivateName - ... - AddPrivateName - NewClass - LeavePrivateEnvironment
2024-05-11 22:54:41 +00:00
Vector<Value> element_keys;
LibJS: Simplify NewClass instruction handler a bit
2025-12-04 09:56:46 +01:00
element_keys.ensure_capacity(m_element_keys_count);
LibJS: Stop using execute_ast_node() for class property evaluation Instead, generate bytecode to execute their AST nodes and save the resulting operands inside the NewClass instruction. Moving property expression evaluation to happen before NewClass execution also moves along creation of new private environment and its population with private members (private members should be visible during property evaluation). Before: - NewClass After: - CreatePrivateEnvironment - AddPrivateName - ... - AddPrivateName - NewClass - LeavePrivateEnvironment
2024-05-11 22:54:41 +00:00
for (size_t i = 0; i < m_element_keys_count; ++i) {
Value element_key;
if (m_element_keys[i].has_value())
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
element_key = interpreter.get(m_element_keys[i].value());
LibJS: Simplify NewClass instruction handler a bit
2025-12-04 09:56:46 +01:00
element_keys.unchecked_append(element_key);
LibJS: Stop using execute_ast_node() for class property evaluation Instead, generate bytecode to execute their AST nodes and save the resulting operands inside the NewClass instruction. Moving property expression evaluation to happen before NewClass execution also moves along creation of new private environment and its population with private members (private members should be visible during property evaluation). Before: - NewClass After: - CreatePrivateEnvironment - AddPrivateName - ... - AddPrivateName - NewClass - LeavePrivateEnvironment
2024-05-11 22:54:41 +00:00
}
LibJS: Simplify NewClass instruction handler a bit
2025-12-04 09:56:46 +01:00
auto& running_execution_context = interpreter.running_execution_context();
LibJS: Wire NewClass to ClassBlueprint Replace the ClassExpression const& reference in the NewClass instruction with a u32 class_blueprint_index. The interpreter now reads from the ClassBlueprint stored on the Executable and calls construct_class() instead of the AST-based create_class_constructor(). Literal field initializers (numbers, booleans, null, strings, negated numbers) are used directly in construct_class() without creating an ECMAScriptFunctionObject, avoiding function creation overhead for common field patterns like `x = 0` or `name = "hello"`. Set class_field_initializer_name on SharedFunctionInstanceData at codegen time for statically-known field keys (identifiers, private identifiers, string literals, and numeric literals). For computed keys, the name is set at runtime in construct_class(). ClassExpression AST nodes are no longer referenced from bytecode.
2026-02-11 00:28:10 +01:00
auto* class_environment = &as<Environment>(interpreter.get(m_class_environment).as_cell());
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
auto& outer_environment = running_execution_context.lexical_environment;
LibJS: Simplify NewClass instruction handler a bit
2025-12-04 09:56:46 +01:00
LibJS: Wire NewClass to ClassBlueprint Replace the ClassExpression const& reference in the NewClass instruction with a u32 class_blueprint_index. The interpreter now reads from the ClassBlueprint stored on the Executable and calls construct_class() instead of the AST-based create_class_constructor(). Literal field initializers (numbers, booleans, null, strings, negated numbers) are used directly in construct_class() without creating an ECMAScriptFunctionObject, avoiding function creation overhead for common field patterns like `x = 0` or `name = "hello"`. Set class_field_initializer_name on SharedFunctionInstanceData at codegen time for statically-known field keys (identifiers, private identifiers, string literals, and numeric literals). For computed keys, the name is set at runtime in construct_class(). ClassExpression AST nodes are no longer referenced from bytecode.
2026-02-11 00:28:10 +01:00
auto const& blueprint = interpreter.current_executable().class_blueprints[m_class_blueprint_index];
LibJS: Simplify NewClass instruction handler a bit
2025-12-04 09:56:46 +01:00
Optional<Utf16FlyString> binding_name;
Utf16FlyString class_name;
LibJS: Wire NewClass to ClassBlueprint Replace the ClassExpression const& reference in the NewClass instruction with a u32 class_blueprint_index. The interpreter now reads from the ClassBlueprint stored on the Executable and calls construct_class() instead of the AST-based create_class_constructor(). Literal field initializers (numbers, booleans, null, strings, negated numbers) are used directly in construct_class() without creating an ECMAScriptFunctionObject, avoiding function creation overhead for common field patterns like `x = 0` or `name = "hello"`. Set class_field_initializer_name on SharedFunctionInstanceData at codegen time for statically-known field keys (identifiers, private identifiers, string literals, and numeric literals). For computed keys, the name is set at runtime in construct_class(). ClassExpression AST nodes are no longer referenced from bytecode.
2026-02-11 00:28:10 +01:00
if (!blueprint.has_name && m_lhs_name.has_value()) {
LibJS: Simplify NewClass instruction handler a bit
2025-12-04 09:56:46 +01:00
class_name = interpreter.get_identifier(m_lhs_name.value());
} else {
LibJS: Wire NewClass to ClassBlueprint Replace the ClassExpression const& reference in the NewClass instruction with a u32 class_blueprint_index. The interpreter now reads from the ClassBlueprint stored on the Executable and calls construct_class() instead of the AST-based create_class_constructor(). Literal field initializers (numbers, booleans, null, strings, negated numbers) are used directly in construct_class() without creating an ECMAScriptFunctionObject, avoiding function creation overhead for common field patterns like `x = 0` or `name = "hello"`. Set class_field_initializer_name on SharedFunctionInstanceData at codegen time for statically-known field keys (identifiers, private identifiers, string literals, and numeric literals). For computed keys, the name is set at runtime in construct_class(). ClassExpression AST nodes are no longer referenced from bytecode.
2026-02-11 00:28:10 +01:00
class_name = blueprint.name;
LibJS: Simplify NewClass instruction handler a bit
2025-12-04 09:56:46 +01:00
binding_name = class_name;
}
LibJS: Wire NewClass to ClassBlueprint Replace the ClassExpression const& reference in the NewClass instruction with a u32 class_blueprint_index. The interpreter now reads from the ClassBlueprint stored on the Executable and calls construct_class() instead of the AST-based create_class_constructor(). Literal field initializers (numbers, booleans, null, strings, negated numbers) are used directly in construct_class() without creating an ECMAScriptFunctionObject, avoiding function creation overhead for common field patterns like `x = 0` or `name = "hello"`. Set class_field_initializer_name on SharedFunctionInstanceData at codegen time for statically-known field keys (identifiers, private identifiers, string literals, and numeric literals). For computed keys, the name is set at runtime in construct_class(). ClassExpression AST nodes are no longer referenced from bytecode.
2026-02-11 00:28:10 +01:00
auto* retval = TRY(construct_class(interpreter.vm(), blueprint, interpreter.current_executable(), class_environment, outer_environment, super_class, element_keys, binding_name, class_name));
LibJS: Simplify NewClass instruction handler a bit
2025-12-04 09:56:46 +01:00
interpreter.set(dst(), retval);
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return {};
}
// 13.5.3.1 Runtime Semantics: Evaluation, https://tc39.es/ecma262/#sec-typeof-operator-runtime-semantics-evaluation
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
ThrowCompletionOr<void> TypeofBinding::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
auto& vm = interpreter.vm();
LibJS/Bytecode: Give TypeofBinding instructions a lookup cache These can use an EnvironmentCoordinate for caching, just like normal binding lookups. Saves a bunch of time for repeated typeof checks.
2024-06-14 13:57:51 +02:00
LibJS: Use [[likely]] annotations for cached environment lookups These will generally be cached the vast majority of the time except on first encounter, and sprinkling [[likely]] gives us a nice boost. 1.10x speed-up on this micro-benchmark: (() => { var a = 3; for (let i = 0; i < 100_000_000; ++i) { a; } eval(""); })();
2025-10-07 16:37:22 +02:00
if (m_cache.is_valid()) [[likely]] {
LibJS/Bytecode: Give TypeofBinding instructions a lookup cache These can use an EnvironmentCoordinate for caching, just like normal binding lookups. Saves a bunch of time for repeated typeof checks.
2024-06-14 13:57:51 +02:00
auto const* environment = interpreter.running_execution_context().lexical_environment.ptr();
LibJS: Limit eval() deoptimization to the containing function scope Previously, when direct eval() was called, we would mark the entire environment chain as "permanently screwed by eval", disabling variable access caching all the way up to the global scope. This was overly conservative. According to the ECMAScript specification, a sloppy direct eval() can only inject var declarations into its containing function's variable environment - it cannot inject variables into parent function scopes. This patch makes two changes: 1. Stop propagating the "screwed by eval" flag at function boundaries. When set_permanently_screwed_by_eval() hits a FunctionEnvironment or GlobalEnvironment, it no longer continues to outer environments. 2. Check each environment during cache lookup traversal. If any environment in the path is marked as screwed, we bail to the slow path. This catches the case where we're inside a function with eval and have a cached coordinate pointing to an outer scope. The second change is necessary because eval can create local variables that shadow outer bindings. When looking up a variable from inside a function that called eval, we can't trust cached coordinates that point to outer scopes, since eval may have created a closer binding. This improves performance for code with nested functions where an inner function uses eval but parent functions perform many variable accesses. The parent functions can now use cached environment coordinates. All 29 new tests verify behavior matches V8.
2026-01-26 20:40:05 +01:00
for (size_t i = 0; i < m_cache.hops; ++i) {
if (environment->is_permanently_screwed_by_eval()) [[unlikely]]
goto slow_path;
LibJS/Bytecode: Give TypeofBinding instructions a lookup cache These can use an EnvironmentCoordinate for caching, just like normal binding lookups. Saves a bunch of time for repeated typeof checks.
2024-06-14 13:57:51 +02:00
environment = environment->outer_environment();
LibJS: Limit eval() deoptimization to the containing function scope Previously, when direct eval() was called, we would mark the entire environment chain as "permanently screwed by eval", disabling variable access caching all the way up to the global scope. This was overly conservative. According to the ECMAScript specification, a sloppy direct eval() can only inject var declarations into its containing function's variable environment - it cannot inject variables into parent function scopes. This patch makes two changes: 1. Stop propagating the "screwed by eval" flag at function boundaries. When set_permanently_screwed_by_eval() hits a FunctionEnvironment or GlobalEnvironment, it no longer continues to outer environments. 2. Check each environment during cache lookup traversal. If any environment in the path is marked as screwed, we bail to the slow path. This catches the case where we're inside a function with eval and have a cached coordinate pointing to an outer scope. The second change is necessary because eval can create local variables that shadow outer bindings. When looking up a variable from inside a function that called eval, we can't trust cached coordinates that point to outer scopes, since eval may have created a closer binding. This improves performance for code with nested functions where an inner function uses eval but parent functions perform many variable accesses. The parent functions can now use cached environment coordinates. All 29 new tests verify behavior matches V8.
2026-01-26 20:40:05 +01:00
}
LibJS: Use [[likely]] annotations for cached environment lookups These will generally be cached the vast majority of the time except on first encounter, and sprinkling [[likely]] gives us a nice boost. 1.10x speed-up on this micro-benchmark: (() => { var a = 3; for (let i = 0; i < 100_000_000; ++i) { a; } eval(""); })();
2025-10-07 16:37:22 +02:00
if (!environment->is_permanently_screwed_by_eval()) [[likely]] {
LibJS/Bytecode: Give TypeofBinding instructions a lookup cache These can use an EnvironmentCoordinate for caching, just like normal binding lookups. Saves a bunch of time for repeated typeof checks.
2024-06-14 13:57:51 +02:00
auto value = TRY(static_cast<DeclarativeEnvironment const&>(*environment).get_binding_value_direct(vm, m_cache.index));
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(dst(), value.typeof_(vm));
LibJS/Bytecode: Give TypeofBinding instructions a lookup cache These can use an EnvironmentCoordinate for caching, just like normal binding lookups. Saves a bunch of time for repeated typeof checks.
2024-06-14 13:57:51 +02:00
return {};
}
LibJS: Limit eval() deoptimization to the containing function scope Previously, when direct eval() was called, we would mark the entire environment chain as "permanently screwed by eval", disabling variable access caching all the way up to the global scope. This was overly conservative. According to the ECMAScript specification, a sloppy direct eval() can only inject var declarations into its containing function's variable environment - it cannot inject variables into parent function scopes. This patch makes two changes: 1. Stop propagating the "screwed by eval" flag at function boundaries. When set_permanently_screwed_by_eval() hits a FunctionEnvironment or GlobalEnvironment, it no longer continues to outer environments. 2. Check each environment during cache lookup traversal. If any environment in the path is marked as screwed, we bail to the slow path. This catches the case where we're inside a function with eval and have a cached coordinate pointing to an outer scope. The second change is necessary because eval can create local variables that shadow outer bindings. When looking up a variable from inside a function that called eval, we can't trust cached coordinates that point to outer scopes, since eval may have created a closer binding. This improves performance for code with nested functions where an inner function uses eval but parent functions perform many variable accesses. The parent functions can now use cached environment coordinates. All 29 new tests verify behavior matches V8.
2026-01-26 20:40:05 +01:00
slow_path:
LibJS/Bytecode: Give TypeofBinding instructions a lookup cache These can use an EnvironmentCoordinate for caching, just like normal binding lookups. Saves a bunch of time for repeated typeof checks.
2024-06-14 13:57:51 +02:00
m_cache = {};
}
// 1. Let val be the result of evaluating UnaryExpression.
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
auto reference = TRY(vm.resolve_binding(interpreter.get_identifier(m_identifier), strict()));
LibJS/Bytecode: Give TypeofBinding instructions a lookup cache These can use an EnvironmentCoordinate for caching, just like normal binding lookups. Saves a bunch of time for repeated typeof checks.
2024-06-14 13:57:51 +02:00
// 2. If val is a Reference Record, then
// a. If IsUnresolvableReference(val) is true, return "undefined".
if (reference.is_unresolvable()) {
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(dst(), PrimitiveString::create(vm, "undefined"_string));
LibJS/Bytecode: Give TypeofBinding instructions a lookup cache These can use an EnvironmentCoordinate for caching, just like normal binding lookups. Saves a bunch of time for repeated typeof checks.
2024-06-14 13:57:51 +02:00
return {};
}
// 3. Set val to ? GetValue(val).
auto value = TRY(reference.get_value(vm));
if (reference.environment_coordinate().has_value())
m_cache = reference.environment_coordinate().value();
// 4. NOTE: This step is replaced in section B.3.6.3.
// 5. Return a String according to Table 41.
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
interpreter.set(dst(), value.typeof_(vm));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return {};
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
void GetCompletionFields::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
{
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto const& completion_cell = static_cast<CompletionCell const&>(interpreter.get(m_completion).as_cell());
interpreter.set(m_value_dst, completion_cell.completion().value());
interpreter.set(m_type_dst, Value(to_underlying(completion_cell.completion().type())));
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
}
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
void SetCompletionType::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
{
Revert "LibJS: Add StackFrame to avoid indirection in VM register access" This reverts commit 36bb2824a67c21a481955a2699b47862976fe692. Although this was faster on my M3 MacBook Pro, other Apple machines disagree, including our benchmark runner. So let's revert it.
2025-04-29 16:08:42 +02:00
auto& completion_cell = static_cast<CompletionCell&>(interpreter.get(m_completion).as_cell());
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
auto completion = completion_cell.completion();
LibJS: Some Bytecode.def fixes - Add missing @nothrow to a bunch of instructions. - Rename fields that were colliding between base and derived class.
2025-11-22 11:55:49 +01:00
completion_cell.set_completion(Completion { m_completion_type, completion.value() });
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
}
LibJS: Generate bytecode for the BlockDeclarationInstantiation AO This necessitated adding some new instructions for creating mutable and immutable bindings.
2025-10-25 14:06:48 +02:00
ThrowCompletionOr<void> CreateImmutableBinding::execute_impl(Bytecode::Interpreter& interpreter) const
{
auto& environment = as<Environment>(interpreter.get(m_environment).as_cell());
LibJS: Some Bytecode.def fixes - Add missing @nothrow to a bunch of instructions. - Rename fields that were colliding between base and derived class.
2025-11-22 11:55:49 +01:00
return environment.create_immutable_binding(interpreter.vm(), interpreter.get_identifier(m_identifier), m_strict_binding);
LibJS: Generate bytecode for the BlockDeclarationInstantiation AO This necessitated adding some new instructions for creating mutable and immutable bindings.
2025-10-25 14:06:48 +02:00
}
ThrowCompletionOr<void> CreateMutableBinding::execute_impl(Bytecode::Interpreter& interpreter) const
{
auto& environment = as<Environment>(interpreter.get(m_environment).as_cell());
return environment.create_mutable_binding(interpreter.vm(), interpreter.get_identifier(m_identifier), m_can_be_deleted);
}
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
ThrowCompletionOr<void> ToObject::execute_impl(Bytecode::Interpreter& interpreter) const
{
interpreter.set(m_dst, TRY(interpreter.get(m_value).to_object(interpreter.vm())));
return {};
}
void ToBoolean::execute_impl(Bytecode::Interpreter& interpreter) const
{
interpreter.set(m_dst, Value(interpreter.get(m_value).to_boolean()));
}
ThrowCompletionOr<void> ToLength::execute_impl(Bytecode::Interpreter& interpreter) const
{
interpreter.set(m_dst, Value { TRY(interpreter.get(m_value).to_length(interpreter.vm())) });
return {};
}
void CreateAsyncFromSyncIterator::execute_impl(Bytecode::Interpreter& interpreter) const
{
auto& vm = interpreter.vm();
auto& realm = interpreter.realm();
auto& iterator = interpreter.get(m_iterator).as_object();
auto next_method = interpreter.get(m_next_method);
auto done = interpreter.get(m_done).as_bool();
auto iterator_record = realm.create<IteratorRecord>(iterator, next_method, done);
auto async_from_sync_iterator = create_async_from_sync_iterator(vm, iterator_record);
auto iterator_object = Object::create(realm, nullptr);
iterator_object->define_direct_property(vm.names.iterator, async_from_sync_iterator.iterator, default_attributes);
iterator_object->define_direct_property(vm.names.nextMethod, async_from_sync_iterator.next_method, default_attributes);
iterator_object->define_direct_property(vm.names.done, Value { async_from_sync_iterator.done }, default_attributes);
interpreter.set(m_dst, iterator_object);
}
ThrowCompletionOr<void> CreateDataPropertyOrThrow::execute_impl(Bytecode::Interpreter& interpreter) const
{
auto& vm = interpreter.vm();
auto& object = interpreter.get(m_object).as_object();
auto property = TRY(interpreter.get(m_property).to_property_key(vm));
auto value = interpreter.get(m_value);
TRY(object.create_data_property_or_throw(property, value));
return {};
}
LibJS: Move IsCallable and IsConstructor out of the interpreter loop There's no reason for these to live in the main interpreter loop.
2025-12-04 19:55:07 +01:00
void IsCallable::execute_impl(Bytecode::Interpreter& interpreter) const
{
interpreter.set(dst(), Value(interpreter.get(value()).is_function()));
}
void IsConstructor::execute_impl(Bytecode::Interpreter& interpreter) const
{
interpreter.set(dst(), Value(interpreter.get(value()).is_constructor()));
}
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
Reference in a new issue Copy permalink