Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-19 15:43:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibJS/Bytecode/Interpreter.cpp

4265 lines
186 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: 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>
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: 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>
#include <LibJS/Runtime/BigInt.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: 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/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
static ByteString format_operand(StringView name, Operand operand, Bytecode::Executable const& executable)
{
StringBuilder builder;
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
if (!name.is_empty())
builder.appendff("\033[32m{}\033[0m:", name);
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
switch (operand.type()) {
case Operand::Type::Register:
LibJS/Bytecode: Pretty-print the `this` register as "this"
2024-05-31 20:59:55 +02:00
if (operand.index() == Register::this_value().index()) {
builder.appendff("\033[33mthis\033[0m");
} else {
builder.appendff("\033[33mreg{}\033[0m", operand.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
break;
case Operand::Type::Local:
LibJS: Preserve information about local variables declaration kind This is required for upcoming change where we want to emit ThrowIfTDZ for assignment expressions only for lexical declarations.
2025-05-05 21:53:19 +03:00
builder.appendff("\033[34m{}~{}\033[0m", executable.local_variable_names[operand.index() - executable.local_index_base].name, operand.index() - executable.local_index_base);
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
break;
LibJS: Add new operand type for function arguments This allows us to directly access passed arguments instead of copying them to register/local first using GetArgument instruction.
2025-04-24 22:10:41 +02:00
case Operand::Type::Argument:
builder.appendff("\033[34marg{}\033[0m", operand.index() - executable.argument_index_base);
break;
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
case Operand::Type::Constant: {
builder.append("\033[36m"sv);
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
auto value = executable.constants[operand.index() - executable.number_of_registers];
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 (value.is_special_empty_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
builder.append("<Empty>"sv);
else if (value.is_boolean())
builder.appendff("Bool({})", value.as_bool() ? "true"sv : "false"sv);
else if (value.is_int32())
builder.appendff("Int32({})", value.as_i32());
else if (value.is_double())
builder.appendff("Double({})", value.as_double());
LibJS/Bytecode: Make primitive bigints be constants Instead of emitting a NewBigInt instruction to construct a primitive bigint from a parsed literal, we now instantiate the BigInt on the heap during codegen.
2024-03-03 11:40:00 +01:00
else if (value.is_bigint())
LibJS: Add a method to stringify a BigInt to UTF-16 And remove the ByteString variant while we are here.
2025-08-07 16:33:10 -04:00
builder.appendff("BigInt({})", MUST(value.as_bigint().to_string()));
LibJS/Bytecode: Make primitive strings be constants Instead of emitting a NewString instruction to construct a primitive string from a parsed literal, we now instantiate the PrimitiveString on the heap during codegen.
2024-03-03 11:34:36 +01:00
else if (value.is_string())
builder.appendff("String(\"{}\")", value.as_string().utf8_string_view());
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
else if (value.is_undefined())
builder.append("Undefined"sv);
else if (value.is_null())
builder.append("Null"sv);
else
builder.appendff("Value: {}", value);
builder.append("\033[0m"sv);
break;
}
default:
VERIFY_NOT_REACHED();
}
return builder.to_byte_string();
}
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
static ByteString format_operand_list(StringView name, ReadonlySpan<Operand> operands, Bytecode::Executable const& executable)
{
StringBuilder builder;
if (!name.is_empty())
LibJS/Bytecode: Make NewArray a variable-length instruction This removes a layer of indirection in the bytecode where we had to make sure all the initializer elements were laid out in sequential registers. Array expressions no longer clobber registers permanently, and they can be reused immediately afterwards.
2024-05-08 12:43:08 +02:00
builder.appendff("\033[32m{}\033[0m:[", name);
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
for (size_t i = 0; i < operands.size(); ++i) {
if (i != 0)
builder.append(", "sv);
builder.appendff("{}", format_operand(""sv, operands[i], executable));
}
builder.append("]"sv);
return builder.to_byte_string();
}
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
static ByteString format_value_list(StringView name, ReadonlySpan<Value> values)
{
StringBuilder builder;
if (!name.is_empty())
LibJS/Bytecode: Fix wonky serialization of instruction value lists
2024-05-06 13:50:21 +02:00
builder.appendff("\033[32m{}\033[0m:[", name);
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
builder.join(", "sv, values);
builder.append("]"sv);
return builder.to_byte_string();
}
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/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
Interpreter::Interpreter(VM& vm)
: m_vm(vm)
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: 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
}
Interpreter::~Interpreter()
{
}
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
ALWAYS_INLINE Value Interpreter::get(Operand op) const
{
return m_registers_and_constants_and_locals_arguments.data()[op.index()];
}
ALWAYS_INLINE void Interpreter::set(Operand op, Value value)
{
m_registers_and_constants_and_locals_arguments.data()[op.index()] = value;
}
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.
// 11. Let script be scriptRecord.[[ECMAScriptCode]].
auto& script = script_record.parse_node();
// 12. Let result be Completion(GlobalDeclarationInstantiation(script, globalEnv)).
auto instantiation_result = script.global_declaration_instantiation(vm, global_environment);
Completion result = instantiation_result.is_throw_completion() ? instantiation_result.throw_completion() : normal_completion(js_undefined());
GC::Ptr<Executable> executable;
if (result.type() == Completion::Type::Normal) {
auto executable_result = JS::Bytecode::Generator::generate_from_ast_node(vm, script, {});
if (executable_result.is_error()) {
if (auto error_string = executable_result.error().to_string(); error_string.is_error())
result = vm.template throw_completion<JS::InternalError>(vm.error_message(JS::VM::ErrorMessage::OutOfMemory));
else if (error_string = String::formatted("TODO({})", error_string.value()); error_string.is_error())
result = vm.template throw_completion<JS::InternalError>(vm.error_message(JS::VM::ErrorMessage::OutOfMemory));
else
result = vm.template throw_completion<JS::InternalError>(error_string.release_value());
} else {
executable = executable_result.release_value();
if (g_dump_bytecode)
executable->dump();
}
}
u32 registers_and_constants_and_locals_count = 0;
if (executable) {
registers_and_constants_and_locals_count = executable->number_of_registers + executable->constants.size() + executable->local_variable_names.size();
}
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: Allocate ExecutionContext memory using alloca() when possible This should be faster than heap allocation. However, heap allocation is still necessary in some cases, such as with generators and async functions.
2025-04-23 23:44:24 +02:00
ExecutionContext* script_context = nullptr;
ALLOCATE_EXECUTION_CONTEXT_ON_NATIVE_STACK(script_context, registers_and_constants_and_locals_count, 0);
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.
// NOTE: This isn't in the spec, but we require it.
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->is_strict_mode = script_record.parse_node().is_strict_mode();
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 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+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: 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+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
auto result_or_error = run_executable(*executable, {}, {});
if (result_or_error.value.is_error())
result = result_or_error.value.release_error();
else {
result = result_or_error.return_register_value.is_special_empty_value() ? normal_completion(js_undefined()) : result_or_error.return_register_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
}
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: Mark Interpreter::handle_exception() as NEVER_INLINE Before this change, we were inlining this function after every handler for instructions that could throw. Forcing it out-of-line shrinks the main bytecode interpreter by 15% and yields a decent 2.5% speedup on JetStream/gcc-loops.cpp.js
2025-04-06 01:29:00 +02:00
NEVER_INLINE Interpreter::HandleExceptionResponse Interpreter::handle_exception(size_t& 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/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
reg(Register::exception()) = exception;
m_scheduled_jump = {};
auto handlers = current_executable().exception_handlers_for_offset(program_counter);
if (!handlers.has_value()) {
return HandleExceptionResponse::ExitFromExecutable;
}
auto& handler = handlers->handler_offset;
auto& finalizer = handlers->finalizer_offset;
LibJS/Bytecode: Cache the running execution context in interpreter
2024-05-11 18:16:27 +02:00
VERIFY(!running_execution_context().unwind_contexts.is_empty());
auto& unwind_context = running_execution_context().unwind_contexts.last();
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
VERIFY(unwind_context.executable == m_current_executable);
if (handler.has_value()) {
program_counter = handler.value();
return HandleExceptionResponse::ContinueInThisExecutable;
}
if (finalizer.has_value()) {
program_counter = finalizer.value();
return HandleExceptionResponse::ContinueInThisExecutable;
}
VERIFY_NOT_REACHED();
}
LibJS/Bytecode: Flatten the interpreter main loop (Clang only) This means inlining all the things. This yields a 40% speedup on the for loop microbenchmark, and everything else gets faster as well. :^) This makes compilation take foreeeever with GCC, so I'm only enabling it for Clang in this commit. We should figure out how to make GCC compile this without timing out CI, since the speedup is amazing.
2024-05-06 16:50:48 +02:00
// FIXME: GCC takes a *long* time to compile with flattening, and it will time out our CI. :|
#if defined(AK_COMPILER_CLANG)
# define FLATTEN_ON_CLANG FLATTEN
#else
# define FLATTEN_ON_CLANG
#endif
FLATTEN_ON_CLANG 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: Mark stack overflow path in run_bytecode() [[unlikely]]
2025-04-28 20:35:59 +02:00
if (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/Bytecode: Cache the running execution context in interpreter
2024-05-11 18:16:27 +02:00
auto& running_execution_context = this->running_execution_context();
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
auto& executable = current_executable();
auto const* bytecode = executable.bytecode.data();
LibJS: Store bytecode VM program counter in ExecutionContext This way it's always automatically correct, and we don't have to manually flush it in push_execution_context(). ~7% speedup on the MicroBench/call* tests :^)
2025-04-28 19:02:56 +02:00
size_t& program_counter = running_execution_context.program_counter;
program_counter = 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/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); \
auto& next_instruction = *reinterpret_cast<Instruction const*>(&bytecode[program_counter]); \
goto* bytecode_dispatch_table[static_cast<size_t>(next_instruction.type())]; \
} while (0)
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/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]);
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
accumulator() = get(instruction.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/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_number() && rhs.is_number()) { \
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; \
goto start; \
} \
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;
}
handle_EnterUnwindContext: {
auto& instruction = *reinterpret_cast<Op::EnterUnwindContext const*>(&bytecode[program_counter]);
enter_unwind_context();
program_counter = instruction.entry_point().address();
goto start;
}
handle_ContinuePendingUnwind: {
auto& instruction = *reinterpret_cast<Op::ContinuePendingUnwind const*>(&bytecode[program_counter]);
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 (auto exception = reg(Register::exception()); !exception.is_special_empty_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
if (handle_exception(program_counter, exception) == HandleExceptionResponse::ExitFromExecutable)
return;
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
goto start;
LibJS/Bytecode: Make each Jump instruction inherit Instruction directly Before this change, all JumpFoo instructions inherited from Jump, which forced the unconditional Jump to have an unusued "false target" member. Also, labels were unnecessarily wrapped in Optional<>. By defining each jump instruction separately, they all shrink in size, and all ambiguity is removed.
2024-05-05 11:52:14 +02:00
}
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 (!saved_return_value().is_special_empty_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
do_return(saved_return_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
if (auto handlers = executable.exception_handlers_for_offset(program_counter); handlers.has_value()) {
if (auto finalizer = handlers.value().finalizer_offset; finalizer.has_value()) {
VERIFY(!running_execution_context.unwind_contexts.is_empty());
auto& unwind_context = running_execution_context.unwind_contexts.last();
VERIFY(unwind_context.executable == m_current_executable);
reg(Register::saved_return_value()) = reg(Register::return_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
reg(Register::return_value()) = 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
program_counter = finalizer.value();
// the unwind_context will be pop'ed when entering the finally block
goto start;
}
}
return;
LibJS/Bytecode: Make each Jump instruction inherit Instruction directly Before this change, all JumpFoo instructions inherited from Jump, which forced the unconditional Jump to have an unusued "false target" member. Also, labels were unnecessarily wrapped in Optional<>. By defining each jump instruction separately, they all shrink in size, and all ambiguity is removed.
2024-05-05 11:52:14 +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
auto const old_scheduled_jump = running_execution_context.previously_scheduled_jumps.take_last();
if (m_scheduled_jump.has_value()) {
program_counter = m_scheduled_jump.value();
m_scheduled_jump = {};
} else {
program_counter = instruction.resume_target().address();
// set the scheduled jump to the old value if we continue
// where we left it
m_scheduled_jump = old_scheduled_jump;
LibJS: Save scheduled jumps when entering unwind contexts These are then restored upon `ContinuePendingUnwind`. This stops us from forgetting where we needed to jump when we do extra try-catches in finally blocks. Co-Authored-By: Jesús "gsus" Lapastora <cyber.gsuscode@gmail.com>
2023-10-21 22:46:40 +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
goto start;
}
handle_ScheduleJump: {
auto& instruction = *reinterpret_cast<Op::ScheduleJump const*>(&bytecode[program_counter]);
m_scheduled_jump = instruction.target().address();
auto finalizer = executable.exception_handlers_for_offset(program_counter).value().finalizer_offset;
VERIFY(finalizer.has_value());
program_counter = finalizer.value();
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; \
goto start; \
} \
} \
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(AsyncIteratorClose);
HANDLE_INSTRUCTION(BitwiseAnd);
HANDLE_INSTRUCTION(BitwiseNot);
HANDLE_INSTRUCTION(BitwiseOr);
HANDLE_INSTRUCTION(BitwiseXor);
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(BlockDeclarationInstantiation);
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(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);
HANDLE_INSTRUCTION(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);
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(ConcatString);
HANDLE_INSTRUCTION(CopyObjectExcludingProperties);
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(DeleteByIdWithThis);
HANDLE_INSTRUCTION(DeleteByValue);
HANDLE_INSTRUCTION(DeleteByValueWithThis);
HANDLE_INSTRUCTION(DeleteVariable);
HANDLE_INSTRUCTION(Div);
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(Dump);
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(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/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: 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(GetNextMethodFromIteratorRecord);
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(GetObjectFromIteratorRecord);
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/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);
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/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(LeaveFinally);
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(LeaveLexicalEnvironment);
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: Make execute_impl() return void for non-throwing ops This way we can't accidentally ignore exceptions.
2024-05-10 17:32:19 +02:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(LeaveUnwindContext);
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/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);
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(NewPrimitiveArray);
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(NewRegExp);
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(NewTypeError);
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(Not);
LibJS: Prepare yield object before re-routing it through finally
2024-05-18 17:25:43 +02:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(PrepareYield);
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);
HANDLE_INSTRUCTION(PutById);
LibJS: Add PutByNumericId and change PutById to be string key only Previously, PutById constructed a PropertyKey from the identifier, which coerced numeric-like strings to numbers. This moves that decision to bytecode generation: the bytecode generator now emits PutByNumericId for numeric keys and PutById for string keys. This removes per-execution parsing from the interpreter. 1.4x speedup on the following microbenchmark: ```js const o = {}; for (let i = 0; i < 10_000_000; i++) { o.a = 1; o.b = 2; o.c = 3; } ```
2025-09-13 16:20:41 +02:00
HANDLE_INSTRUCTION(PutByNumericId);
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(PutByIdWithThis);
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(PutByValue);
HANDLE_INSTRUCTION(PutByValueWithThis);
HANDLE_INSTRUCTION(PutPrivateById);
HANDLE_INSTRUCTION(ResolveSuperBase);
HANDLE_INSTRUCTION(ResolveThisBinding);
LibJS/Bytecode: Make execute_impl() return void for non-throwing ops This way we can't accidentally ignore exceptions.
2024-05-10 17:32:19 +02:00
HANDLE_INSTRUCTION_WITHOUT_EXCEPTION_CHECK(RestoreScheduledJump);
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(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/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(Throw);
HANDLE_INSTRUCTION(ThrowIfNotObject);
HANDLE_INSTRUCTION(ThrowIfNullish);
HANDLE_INSTRUCTION(ThrowIfTDZ);
HANDLE_INSTRUCTION(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);
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]);
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: 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/Bytecode: Streamline return/yield flow a bit in the interpreter
2024-05-10 07:56:39 +02:00
// Note: A `yield` statement will not go through a finally statement,
// hence we need to set a flag to not do so,
// but we generate a Yield Operation in the case of returns in
// generators as well, so we need to check if it will actually
// continue or is a `return` in disguise
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
{
return m_identifier_table.data()[index.value];
}
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
Interpreter::ResultAndReturnRegister Interpreter::run_executable(Executable& executable, Optional<size_t> entry_point, Value initial_accumulator_value)
LibJS: Move bytecode interpreter's inner loop to its own function
2023-09-26 16:41:42 +02:00
{
dbgln_if(JS_BYTECODE_DEBUG, "Bytecode::Interpreter will run unit {:p}", &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
TemporaryChange restore_executable { m_current_executable, GC::Ptr { executable } };
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
TemporaryChange restore_saved_jump { m_scheduled_jump, Optional<size_t> {} };
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
TemporaryChange restore_realm { m_realm, GC::Ptr { vm().current_realm() } };
TemporaryChange restore_global_object { m_global_object, GC::Ptr { m_realm->global_object() } };
TemporaryChange restore_global_declarative_environment { m_global_declarative_environment, GC::Ptr { m_realm->global_environment().declarative_record() } };
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
TemporaryChange restore_identifier_table { m_identifier_table, executable.identifier_table->identifiers() };
LibJS: Move bytecode interpreter's inner loop to its own function
2023-09-26 16:41:42 +02:00
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
auto& running_execution_context = vm().running_execution_context();
LibJS/Bytecode: Display local variable names in bytecode dumps Instead of displaying locals as "locN", we now show them as "name~N". This makes it a lot easier to follow bytecode dumps, especially in longer functions. Note that we keep displaying the local index, to avoid confusion in case there are multiple separate locals with the same name in one executable.
2024-06-13 21:19:06 +02:00
u32 registers_and_constants_and_locals_count = executable.number_of_registers + executable.constants.size() + executable.local_variable_names.size();
LibJS: Put vector of regs+consts+locals+args in tail of ExecutionContext By doing that we avoid doing separate allocation for each such vector, which was really expensive on js heavy websites. For example this change helps to get EC allocation down from ~17% to ~2% on Google Maps. This comes at cost of adding extra complexity to custom execution context allocator, because EC no longer has fixed size and we need to maintain a list of buckets.
2025-04-23 19:44:54 +02:00
VERIFY(registers_and_constants_and_locals_count <= running_execution_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/Bytecode: Cache the running execution context in interpreter
2024-05-11 18:16:27 +02:00
TemporaryChange restore_running_execution_context { m_running_execution_context, &running_execution_context };
LibJS: Add new operand type for function arguments This allows us to directly access passed arguments instead of copying them to register/local first using GetArgument instruction.
2025-04-24 22:10:41 +02:00
TemporaryChange restore_registers_and_constants_and_locals { m_registers_and_constants_and_locals_arguments, running_execution_context.registers_and_constants_and_locals_and_arguments_span() };
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
reg(Register::accumulator()) = initial_accumulator_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
reg(Register::return_value()) = js_special_empty_value();
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())
reg(Register::this_value()) = running_execution_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
running_execution_context.executable = &executable;
LibJS: Lazily collect stack trace information The previous implementation was calling `backtrace()` for every function call, which is quite slow. Instead, this implementation provides VM::stack_trace() which unwinds the native stack, maps it through NativeExecutable::get_source_range and combines it with source ranges from interpreted call frames.
2023-11-01 00:39:28 +01:00
LibJS: Put vector of regs+consts+locals+args in tail of ExecutionContext By doing that we avoid doing separate allocation for each such vector, which was really expensive on js heavy websites. For example this change helps to get EC allocation down from ~17% to ~2% on Google Maps. This comes at cost of adding extra complexity to custom execution context allocator, because EC no longer has fixed size and we need to maintain a list of buckets.
2025-04-23 19:44:54 +02:00
auto* registers_and_constants_and_locals_and_arguments = running_execution_context.registers_and_constants_and_locals_and_arguments();
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.constants.size(); ++i) {
LibJS: Put vector of regs+consts+locals+args in tail of ExecutionContext By doing that we avoid doing separate allocation for each such vector, which was really expensive on js heavy websites. For example this change helps to get EC allocation down from ~17% to ~2% on Google Maps. This comes at cost of adding extra complexity to custom execution context allocator, because EC no longer has fixed size and we need to maintain a list of buckets.
2025-04-23 19:44:54 +02:00
registers_and_constants_and_locals_and_arguments[executable.number_of_registers + i] = executable.constants[i];
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: Rename Bytecode::ExecutionUnit => Bytecode::Executable
2021-06-09 09:11:20 +02:00
dbgln_if(JS_BYTECODE_DEBUG, "Bytecode::Interpreter did run unit {:p}", &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+LibWeb: Join arguments into vector of registers+constants+locals This is better because: - Better data locality - Allocate vector for registers+constants+locals+arguments in one go instead of allocating two vectors separately
2025-04-23 00:57:07 +02:00
if (registers_and_constants_and_locals_and_arguments[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+LibWeb: Join arguments into vector of registers+constants+locals This is better because: - Better data locality - Allocate vector for registers+constants+locals+arguments in one go instead of allocating two vectors separately
2025-04-23 00:57:07 +02:00
value_string = registers_and_constants_and_locals_and_arguments[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: Keep return value in a call frame register
2023-09-26 15:32:46 +02:00
auto return_value = js_undefined();
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::return_value()).is_special_empty_value())
LibJS: Keep return value in a call frame register
2023-09-26 15:32:46 +02:00
return_value = reg(Register::return_value());
LibJS: Keep current exception in a call frame register Instead of keeping it in a Bytecode::Interpreter member, move it into a dedicated call frame register.
2023-09-26 11:57:42 +02:00
auto exception = reg(Register::exception());
LibJS/Bytecode: Keep saved return value in call frame register This fixes an issue where returning inside a `try` block and then calling a function inside `finally` would clobber the saved return value from the `try` block. Note that we didn't need to change the base of register allocation, since it was already 1 too high. With this fixed, https://microsoft.com/edge loads in bytecode mode. :^) Thanks to Luke for reducing the issue!
2023-07-21 17:30:07 +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: 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 (!exception.is_special_empty_value())
LibJS: Put vector of regs+consts+locals+args in tail of ExecutionContext By doing that we avoid doing separate allocation for each such vector, which was really expensive on js heavy websites. For example this change helps to get EC allocation down from ~17% to ~2% on Google Maps. This comes at cost of adding extra complexity to custom execution context allocator, because EC no longer has fixed size and we need to maintain a list of buckets.
2025-04-23 19:44:54 +02:00
return { throw_completion(exception), registers_and_constants_and_locals_and_arguments[0] };
return { return_value, registers_and_constants_and_locals_and_arguments[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: Use static unwind mappings for unwind related functions
2023-10-20 00:33:51 +02:00
void Interpreter::enter_unwind_context()
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
{
LibJS/Bytecode: Cache the running execution context in interpreter
2024-05-11 18:16:27 +02:00
running_execution_context().unwind_contexts.empend(
LibJS/Bytecode: Restore old environments when an exception is caught Unwind contexts now remember the lexical and variable environments in effect when they were created. If an exception is caught, we revert to those environments in the running execution context.
2023-05-13 18:53:14 +02:00
m_current_executable,
LibJS/Bytecode: Cache the running execution context in interpreter
2024-05-11 18:16:27 +02:00
running_execution_context().lexical_environment);
running_execution_context().previously_scheduled_jumps.append(m_scheduled_jump);
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
m_scheduled_jump = {};
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
}
void Interpreter::leave_unwind_context()
{
LibJS/Bytecode: Cache the running execution context in interpreter
2024-05-11 18:16:27 +02:00
running_execution_context().unwind_contexts.take_last();
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +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();
auto& context = running_execution_context().unwind_contexts.last();
VERIFY(!context.handler_called);
VERIFY(context.executable == &current_executable());
context.handler_called = true;
running_execution_context().lexical_environment = context.lexical_environment;
}
LibJS: Restore scheduled jumps in catch blocks without finalizers
2024-04-11 11:07:35 +02:00
void Interpreter::restore_scheduled_jump()
{
LibJS/Bytecode: Cache the running execution context in interpreter
2024-05-11 18:16:27 +02:00
m_scheduled_jump = running_execution_context().previously_scheduled_jumps.take_last();
LibJS: Restore scheduled jumps in catch blocks without finalizers
2024-04-11 11:07:35 +02:00
}
LibJS: Cleanup unwind state when transferring control out of a finalizer This does two things: * Clear exceptions when transferring control out of a finalizer Otherwise they would resurface at the end of the next finalizer (see test the new test case), or at the end of a function * Pop one scheduled jump when transferring control out of a finalizer This removes one old FIXME
2024-04-11 11:58:18 +02:00
void Interpreter::leave_finally()
{
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
reg(Register::exception()) = js_special_empty_value();
LibJS/Bytecode: Cache the running execution context in interpreter
2024-05-11 18:16:27 +02:00
m_scheduled_jump = running_execution_context().previously_scheduled_jumps.take_last();
LibJS: Cleanup unwind state when transferring control out of a finalizer This does two things: * Clear exceptions when transferring control out of a finalizer Otherwise they would resurface at the end of the next finalizer (see test the new test case), or at the end of a function * Pop one scheduled jump when transferring control out of a finalizer This removes one old FIXME
2024-04-11 11:58:18 +02:00
}
LibJS/JIT: Support the EnterObjectEnvironment bytecode instruction We can now use `with` statements in jitted code. :^)
2023-11-12 00:12:21 +01:00
void Interpreter::enter_object_environment(Object& object)
{
LibJS/Bytecode: Cache the running execution context in interpreter
2024-05-11 18:16:27 +02:00
auto& old_environment = running_execution_context().lexical_environment;
running_execution_context().saved_lexical_environments.append(old_environment);
running_execution_context().lexical_environment = new_object_environment(object, true, old_environment);
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+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
ThrowCompletionOr<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: 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 executable_result = Bytecode::Generator::generate_from_ast_node(vm, node, kind);
if (executable_result.is_error())
return vm.throw_completion<InternalError>(ErrorType::NotImplemented, TRY_OR_THROW_OOM(vm, executable_result.error().to_string()));
auto bytecode_executable = executable_result.release_value();
bytecode_executable->name = name;
if (Bytecode::g_dump_bytecode)
bytecode_executable->dump();
return bytecode_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
ThrowCompletionOr<GC::Ref<Bytecode::Executable>> compile(VM& vm, ECMAScriptFunctionObject const& function)
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 const& name = function.name();
auto executable_result = Bytecode::Generator::generate_from_function(vm, function);
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 (executable_result.is_error())
return vm.throw_completion<InternalError>(ErrorType::NotImplemented, TRY_OR_THROW_OOM(vm, executable_result.error().to_string()));
auto bytecode_executable = executable_result.release_value();
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;
}
Everywhere: Warn on function definitions without prototypes If no header includes the prototype of a function, then it cannot be used from outside the translation unit it was defined in. In that case, it should be marked as `static`, in order to avoid possible ODR problems, unnecessary exported symbols, and allow the compiler to better optimize those. If this warning triggers in a function defined in a header, `inline` needs to be added, otherwise if the header is included in more than one TU, it will fail to link with a duplicate definition error. The reason this diff got so big is that Lagom-only code wasn't built with this flag even in Serenity times.
2024-07-14 18:29:33 +02:00
static 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);
}
Everywhere: Warn on function definitions without prototypes If no header includes the prototype of a function, then it cannot be used from outside the translation unit it was defined in. In that case, it should be marked as `static`, in order to avoid possible ODR problems, unnecessary exported symbols, and allow the compiler to better optimize those. If this warning triggers in a function defined in a header, `inline` needs to be added, otherwise if the header is included in more than one TU, it will fail to link with a duplicate definition error. The reason this diff got so big is that Lagom-only code wasn't built with this flag even in Serenity times.
2024-07-14 18:29:33 +02:00
static 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);
}
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
template<typename BaseType, typename PropertyType>
ALWAYS_INLINE Completion throw_null_or_undefined_property_access(VM& vm, Value base_value, BaseType const& base_identifier, PropertyType const& property_identifier)
{
VERIFY(base_value.is_nullish());
bool has_base_identifier = true;
bool has_property_identifier = true;
if constexpr (requires { base_identifier.has_value(); })
has_base_identifier = base_identifier.has_value();
if constexpr (requires { property_identifier.has_value(); })
has_property_identifier = property_identifier.has_value();
if (has_base_identifier && has_property_identifier)
return vm.throw_completion<TypeError>(ErrorType::ToObjectNullOrUndefinedWithPropertyAndName, property_identifier, base_value, base_identifier);
if (has_property_identifier)
return vm.throw_completion<TypeError>(ErrorType::ToObjectNullOrUndefinedWithProperty, property_identifier, base_value);
if (has_base_identifier)
return vm.throw_completion<TypeError>(ErrorType::ToObjectNullOrUndefinedWithName, base_identifier, base_value);
return vm.throw_completion<TypeError>(ErrorType::ToObjectNullOrUndefined);
}
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 GC::Ptr<Object> base_object_for_get_impl(VM& vm, Value base_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 (base_value.is_object()) [[likely]]
return base_value.as_object();
// OPTIMIZATION: For various primitives we can avoid actually creating a new object for them.
auto& realm = *vm.current_realm();
if (base_value.is_string())
return realm.intrinsics().string_prototype();
if (base_value.is_number())
return realm.intrinsics().number_prototype();
if (base_value.is_boolean())
return realm.intrinsics().boolean_prototype();
if (base_value.is_bigint())
return realm.intrinsics().bigint_prototype();
if (base_value.is_symbol())
return realm.intrinsics().symbol_prototype();
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 nullptr;
}
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
{
if (auto base_object = base_object_for_get_impl(vm, 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
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
{
if (auto base_object = base_object_for_get_impl(vm, 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
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
}
enum class GetByIdMode {
Normal,
Length,
};
template<GetByIdMode mode = GetByIdMode::Normal>
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_id(VM& vm, Optional<IdentifierTableIndex> base_identifier, IdentifierTableIndex property, Value base_value, Value this_value, PropertyLookupCache& cache, 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
{
if constexpr (mode == GetByIdMode::Length) {
if (base_value.is_string()) {
LibJS: Add and use PrimitiveString::length_in_utf16_code_units I was investigating an optimization in this area, and while it didn't seem to have a noticable improvement, it still seems useful to apply this change.
2025-05-04 00:06:34 +12:00
return Value(base_value.as_string().length_in_utf16_code_units());
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
auto base_obj = TRY(base_object_for_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
if constexpr (mode == GetByIdMode::Length) {
// OPTIMIZATION: Fast path for the magical "length" property on Array objects.
if (base_obj->has_magical_length_property()) {
return Value { base_obj->indexed_properties().array_like_size() };
}
}
auto& shape = base_obj->shape();
LibJS: Capture PrototypeChainValidity before executing `internal_get()` - Capture PrototypeChainValidity before invoking `internal_get()`. A getter may mutate the prototype chain (e.g., delete itself). Capturing earlier ensures such mutations invalidate the cached entry and prevent stale GetById hits. - When caching, take PrototypeChainValidity from the base object (receiver), not from the prototype where the property was found. Otherwise, changes to an intermediate prototype between the base object and the cached prototype object go unnoticed, leading to incorrect cache hits.
2025-09-18 02:28:52 +02:00
GC::Ptr<PrototypeChainValidity> prototype_chain_validity;
if (shape.prototype())
prototype_chain_validity = shape.prototype()->shape().prototype_chain_validity();
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
for (auto& cache_entry : cache.entries) {
if (cache_entry.prototype) {
// OPTIMIZATION: If the prototype chain hasn't been mutated in a way that would invalidate the cache, we can use it.
bool can_use_cache = [&]() -> bool {
if (&shape != cache_entry.shape)
return false;
if (!cache_entry.prototype_chain_validity)
return false;
if (!cache_entry.prototype_chain_validity->is_valid())
return false;
return true;
}();
if (can_use_cache) {
auto value = cache_entry.prototype->get_direct(cache_entry.property_offset.value());
if (value.is_accessor())
return TRY(call(vm, value.as_accessor().getter(), this_value));
return value;
}
} else if (&shape == cache_entry.shape) {
// OPTIMIZATION: If the shape of the object hasn't changed, we can use the cached property offset.
auto value = base_obj->get_direct(cache_entry.property_offset.value());
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())
return TRY(call(vm, value.as_accessor().getter(), this_value));
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
}
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: 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 value = TRY(base_obj->internal_get(executable.get_identifier(property), this_value, &cacheable_metadata));
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: Skip caching get_by_id() if object's shape is changed by a getter Fixes a bug that reproduces with the following steps: 1. Create an object with a getter for property "a" in its prototype, where the getter adds an "a" property to the object itself. 2. Call the "a" getter in a loop for the first time. This triggers caching of metadata indicating that the "a" property is located in the prototype chain. 3. Call the "a" getter in a loop for the second time. Oops, the cache says the getter is in the prototype chain, but the object now also has its own "a" property that was added by the first getter call.
2025-05-20 23:42:17 +03:00
// If internal_get() caused object's shape change, we can no longer be sure
// that collected metadata is valid, e.g. if getter in prototype chain added
// property with the same name into the object itself.
if (&shape == &base_obj->shape()) {
auto get_cache_slot = [&] -> PropertyLookupCache::Entry& {
for (size_t i = cache.entries.size() - 1; i >= 1; --i) {
cache.entries[i] = cache.entries[i - 1];
}
cache.entries[0] = {};
return cache.entries[0];
};
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: Skip caching get_by_id() if object's shape is changed by a getter Fixes a bug that reproduces with the following steps: 1. Create an object with a getter for property "a" in its prototype, where the getter adds an "a" property to the object itself. 2. Call the "a" getter in a loop for the first time. This triggers caching of metadata indicating that the "a" property is located in the prototype chain. 3. Call the "a" getter in a loop for the second time. Oops, the cache says the getter is in the prototype chain, but the object now also has its own "a" property that was added by the first getter call.
2025-05-20 23:42:17 +03:00
auto& entry = get_cache_slot();
entry.shape = shape;
entry.property_offset = cacheable_metadata.property_offset.value();
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
} else if (cacheable_metadata.type == CacheableGetPropertyMetadata::Type::GetPropertyInPrototypeChain) {
LibJS: Skip caching get_by_id() if object's shape is changed by a getter Fixes a bug that reproduces with the following steps: 1. Create an object with a getter for property "a" in its prototype, where the getter adds an "a" property to the object itself. 2. Call the "a" getter in a loop for the first time. This triggers caching of metadata indicating that the "a" property is located in the prototype chain. 3. Call the "a" getter in a loop for the second time. Oops, the cache says the getter is in the prototype chain, but the object now also has its own "a" property that was added by the first getter call.
2025-05-20 23:42:17 +03:00
auto& entry = get_cache_slot();
entry.shape = &base_obj->shape();
entry.property_offset = cacheable_metadata.property_offset.value();
entry.prototype = *cacheable_metadata.prototype;
LibJS: Capture PrototypeChainValidity before executing `internal_get()` - Capture PrototypeChainValidity before invoking `internal_get()`. A getter may mutate the prototype chain (e.g., delete itself). Capturing earlier ensures such mutations invalidate the cached entry and prevent stale GetById hits. - When caching, take PrototypeChainValidity from the base object (receiver), not from the prototype where the property was found. Otherwise, changes to an intermediate prototype between the base object and the cached prototype object go unnoticed, leading to incorrect cache hits.
2025-09-18 02:28:52 +02:00
entry.prototype_chain_validity = *prototype_chain_validity;
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
}
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;
}
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.
if (base_value.is_object() && property_key_value.is_int32() && property_key_value.as_i32() >= 0) {
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));
}
inline ThrowCompletionOr<Value> get_global(Interpreter& interpreter, IdentifierTableIndex identifier_index, GlobalVariableCache& cache)
{
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: 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
if (&shape == cache.entries[0].shape) {
auto value = binding_object.get_direct(cache.entries[0].property_offset.value());
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())
return TRY(call(vm, value.as_accessor().getter(), js_undefined()));
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: 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 TRY(module_environment.get_binding_value(vm, identifier, vm.in_strict_mode()));
}
}
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: 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 TRY(declarative_record.get_binding_value(vm, identifier, vm.in_strict_mode()));
}
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
CacheableGetPropertyMetadata cacheable_metadata;
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 value = TRY(binding_object.internal_get(identifier, js_undefined(), &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: 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: Rename Bytecode::Op::PropertyKind => Bytecode::PutKind This is only used to specify how a property is being added to an object by Put* instructions, so let's call it PutKind. Also add an enumeration X macro for it to prepare for upcoming specializations.
2025-10-10 11:16:02 +02:00
inline ThrowCompletionOr<void> put_by_property_key(VM& vm, Value base, Value this_value, Value value, Optional<Utf16FlyString const&> const& base_identifier, PropertyKey name, PutKind kind, PropertyLookupCache* caches = nullptr)
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
{
// Better error message than to_object would give
if (vm.in_strict_mode() && base.is_nullish())
return vm.throw_completion<TypeError>(ErrorType::ReferenceNullishSetProperty, name, base.to_string_without_side_effects());
// a. Let baseObj be ? ToObject(V.[[Base]]).
auto maybe_object = base.to_object(vm);
if (maybe_object.is_error())
return throw_null_or_undefined_property_access(vm, base, base_identifier, name);
auto object = maybe_object.release_value();
LibJS: Rename Bytecode::Op::PropertyKind => Bytecode::PutKind This is only used to specify how a property is being added to an object by Put* instructions, so let's call it PutKind. Also add an enumeration X macro for it to prepare for upcoming specializations.
2025-10-10 11:16:02 +02:00
if (kind == PutKind::Getter || kind == PutKind::Setter) {
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
// The generator should only pass us functions for getters and setters.
VERIFY(value.is_function());
}
switch (kind) {
LibJS: Rename Bytecode::Op::PropertyKind => Bytecode::PutKind This is only used to specify how a property is being added to an object by Put* instructions, so let's call it PutKind. Also add an enumeration X macro for it to prepare for upcoming specializations.
2025-10-10 11:16:02 +02:00
case PutKind::Getter: {
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& function = value.as_function();
LibJS: Remove unnecessary FunctionObject::name() virtual This allows us to remove the BoundFunction::m_name field, which we were initializing with a formatted FlyString on every function binding, despite never using it for anything.
2025-04-09 22:31:12 +02:00
if (is<ECMAScriptFunctionObject>(function) && static_cast<ECMAScriptFunctionObject const&>(function).name().is_empty())
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
static_cast<ECMAScriptFunctionObject*>(&function)->set_name(Utf16String::formatted("get {}", name));
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
object->define_direct_accessor(name, &function, nullptr, Attribute::Configurable | Attribute::Enumerable);
break;
}
LibJS: Rename Bytecode::Op::PropertyKind => Bytecode::PutKind This is only used to specify how a property is being added to an object by Put* instructions, so let's call it PutKind. Also add an enumeration X macro for it to prepare for upcoming specializations.
2025-10-10 11:16:02 +02:00
case PutKind::Setter: {
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& function = value.as_function();
LibJS: Remove unnecessary FunctionObject::name() virtual This allows us to remove the BoundFunction::m_name field, which we were initializing with a formatted FlyString on every function binding, despite never using it for anything.
2025-04-09 22:31:12 +02:00
if (is<ECMAScriptFunctionObject>(function) && static_cast<ECMAScriptFunctionObject const&>(function).name().is_empty())
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
static_cast<ECMAScriptFunctionObject*>(&function)->set_name(Utf16String::formatted("set {}", name));
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
object->define_direct_accessor(name, nullptr, &function, Attribute::Configurable | Attribute::Enumerable);
break;
}
LibJS: Rename Bytecode::Op::PropertyKind => Bytecode::PutKind This is only used to specify how a property is being added to an object by Put* instructions, so let's call it PutKind. Also add an enumeration X macro for it to prepare for upcoming specializations.
2025-10-10 11:16:02 +02:00
case PutKind::Normal: {
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
auto this_value_object = MUST(this_value.to_object(vm));
auto& from_shape = this_value_object->shape();
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
if (caches) {
LibJS: Make PutById inline cache polymorphic (4 shapes) 2.44x speedup on MicroBench/pic-put-own.js 1.48x speedup on MicroBench/pic-put-pchain.js
2025-05-06 13:58:27 +02:00
for (auto& cache : caches->entries) {
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
switch (cache.type) {
case PropertyLookupCache::Entry::Type::Empty:
break;
case PropertyLookupCache::Entry::Type::ChangePropertyInPrototypeChain: {
if (!cache.prototype)
break;
LibJS: Make PutById inline cache polymorphic (4 shapes) 2.44x speedup on MicroBench/pic-put-own.js 1.48x speedup on MicroBench/pic-put-pchain.js
2025-05-06 13:58:27 +02:00
// OPTIMIZATION: If the prototype chain hasn't been mutated in a way that would invalidate the cache, we can use it.
bool can_use_cache = [&]() -> bool {
if (&object->shape() != cache.shape)
return false;
if (!cache.prototype_chain_validity)
return false;
if (!cache.prototype_chain_validity->is_valid())
return false;
return true;
}();
if (can_use_cache) {
auto value_in_prototype = cache.prototype->get_direct(cache.property_offset.value());
if (value_in_prototype.is_accessor()) {
TRY(call(vm, value_in_prototype.as_accessor().setter(), this_value, value));
return {};
}
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
}
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
break;
}
case PropertyLookupCache::Entry::Type::ChangeOwnProperty: {
if (cache.shape != &object->shape())
break;
LibJS: Make PutById inline cache polymorphic (4 shapes) 2.44x speedup on MicroBench/pic-put-own.js 1.48x speedup on MicroBench/pic-put-pchain.js
2025-05-06 13:58:27 +02:00
auto value_in_object = object->get_direct(cache.property_offset.value());
if (value_in_object.is_accessor()) {
TRY(call(vm, value_in_object.as_accessor().setter(), this_value, value));
} else {
object->put_direct(*cache.property_offset, value);
}
return {};
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
}
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
case PropertyLookupCache::Entry::Type::AddOwnProperty: {
// OPTIMIZATION: If the object's shape is the same as the one cached before adding the new property, we can
// reuse the resulting shape from the cache.
if (cache.from_shape != &object->shape())
break;
if (!cache.shape)
break;
// The cache is invalid if the prototype chain has been mutated, since such a mutation could have added a setter for the property.
if (cache.prototype_chain_validity && !cache.prototype_chain_validity->is_valid())
break;
object->unsafe_set_shape(*cache.shape);
object->put_direct(*cache.property_offset, value);
return {};
}
default:
VERIFY_NOT_REACHED();
}
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
}
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 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: 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
bool succeeded = TRY(object->internal_set(name, value, this_value, &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
auto get_cache_slot = [&] -> PropertyLookupCache::Entry& {
for (size_t i = caches->entries.size() - 1; i >= 1; --i) {
caches->entries[i] = caches->entries[i - 1];
}
caches->entries[0] = {};
return caches->entries[0];
};
if (succeeded && caches && cacheable_metadata.type == CacheableSetPropertyMetadata::Type::AddOwnProperty) {
auto& cache = get_cache_slot();
cache.type = PropertyLookupCache::Entry::Type::AddOwnProperty;
cache.from_shape = from_shape;
cache.property_offset = cacheable_metadata.property_offset.value();
cache.shape = &object->shape();
if (cacheable_metadata.prototype) {
cache.prototype_chain_validity = *cacheable_metadata.prototype->shape().prototype_chain_validity();
}
}
LibJS: Skip caching get_by_id() if object's shape is changed by a getter Fixes a bug that reproduces with the following steps: 1. Create an object with a getter for property "a" in its prototype, where the getter adds an "a" property to the object itself. 2. Call the "a" getter in a loop for the first time. This triggers caching of metadata indicating that the "a" property is located in the prototype chain. 3. Call the "a" getter in a loop for the second time. Oops, the cache says the getter is in the prototype chain, but the object now also has its own "a" property that was added by the first getter call.
2025-05-20 23:42:17 +03:00
// If internal_set() caused object's shape change, we can no longer be sure
// that collected metadata is valid, e.g. if setter in prototype chain added
// property with the same name into the object itself.
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 (succeeded && caches && &from_shape == &object->shape()) {
LibJS: Make PutById inline cache polymorphic (4 shapes) 2.44x speedup on MicroBench/pic-put-own.js 1.48x speedup on MicroBench/pic-put-pchain.js
2025-05-06 13:58:27 +02:00
auto& cache = get_cache_slot();
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
switch (cacheable_metadata.type) {
case CacheableSetPropertyMetadata::Type::AddOwnProperty:
// Something went wrong if we ended up here, because cacheable addition of a new property should've changed the shape.
VERIFY_NOT_REACHED();
break;
case CacheableSetPropertyMetadata::Type::ChangeOwnProperty:
cache.type = PropertyLookupCache::Entry::Type::ChangeOwnProperty;
LibJS: Make PutById inline cache polymorphic (4 shapes) 2.44x speedup on MicroBench/pic-put-own.js 1.48x speedup on MicroBench/pic-put-pchain.js
2025-05-06 13:58:27 +02:00
cache.shape = object->shape();
cache.property_offset = cacheable_metadata.property_offset.value();
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
break;
case CacheableSetPropertyMetadata::Type::ChangePropertyInPrototypeChain:
cache.type = PropertyLookupCache::Entry::Type::ChangePropertyInPrototypeChain;
LibJS: Make PutById inline cache polymorphic (4 shapes) 2.44x speedup on MicroBench/pic-put-own.js 1.48x speedup on MicroBench/pic-put-pchain.js
2025-05-06 13:58:27 +02:00
cache.shape = object->shape();
cache.property_offset = cacheable_metadata.property_offset.value();
cache.prototype = *cacheable_metadata.prototype;
cache.prototype_chain_validity = *cacheable_metadata.prototype->shape().prototype_chain_validity();
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
break;
case CacheableSetPropertyMetadata::Type::NotCacheable:
break;
default:
VERIFY_NOT_REACHED();
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
}
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: 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
if (!succeeded && vm.in_strict_mode()) [[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
if (base.is_object())
return vm.throw_completion<TypeError>(ErrorType::ReferenceNullishSetProperty, name, base.to_string_without_side_effects());
LibJS: Rename Value::typeof() to Value::typeof_() This to avoid clashing with the GCC typeof extension, which apparently confuses clang-format.
2024-07-23 10:25:06 +02:00
return vm.throw_completion<TypeError>(ErrorType::ReferencePrimitiveSetProperty, name, base.typeof_(vm)->utf8_string(), base.to_string_without_side_effects());
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
}
break;
}
LibJS: Rename Bytecode::Op::PropertyKind => Bytecode::PutKind This is only used to specify how a property is being added to an object by Put* instructions, so let's call it PutKind. Also add an enumeration X macro for it to prepare for upcoming specializations.
2025-10-10 11:16:02 +02:00
case PutKind::Own:
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
object->define_direct_property(name, value, Attribute::Enumerable | Attribute::Writable | Attribute::Configurable);
break;
LibJS: Rename Bytecode::Op::PropertyKind => Bytecode::PutKind This is only used to specify how a property is being added to an object by Put* instructions, so let's call it PutKind. Also add an enumeration X macro for it to prepare for upcoming specializations.
2025-10-10 11:16:02 +02:00
case PutKind::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 (value.is_object() || value.is_null())
MUST(object->internal_set_prototype_of(value.is_object() ? &value.as_object() : nullptr));
break;
}
return {};
}
inline ThrowCompletionOr<Value> perform_call(Interpreter& interpreter, Value this_value, Op::CallType call_type, Value callee, ReadonlySpan<Value> argument_values)
{
auto& vm = interpreter.vm();
auto& function = callee.as_function();
Value return_value;
if (call_type == Op::CallType::DirectEval) {
if (callee == interpreter.realm().intrinsics().eval_function())
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_value = TRY(perform_eval(vm, !argument_values.is_empty() ? argument_values[0] : js_undefined(), vm.in_strict_mode() ? CallerMode::Strict : CallerMode::NonStrict, EvalMode::Direct));
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
else
return_value = TRY(JS::call(vm, function, this_value, argument_values));
} else if (call_type == Op::CallType::Call)
return_value = TRY(JS::call(vm, function, this_value, argument_values));
else
return_value = TRY(construct(vm, function, argument_values));
return return_value;
}
static inline Completion throw_type_error_for_callee(Bytecode::Interpreter& interpreter, Value callee, StringView callee_type, Optional<StringTableIndex> const& expression_string)
{
auto& vm = interpreter.vm();
if (expression_string.has_value())
LibJS: Make Optional<StringTableIndex> use less space We can use the index's invalid state to signal an empty optional. This makes Optional<StringTableIndex> 4 bytes instead of 8, shrinking every bytecode instruction that uses these.
2025-04-05 21:46:37 +02:00
return vm.throw_completion<TypeError>(ErrorType::IsNotAEvaluatedFrom, callee.to_string_without_side_effects(), 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
return vm.throw_completion<TypeError>(ErrorType::IsNotA, callee.to_string_without_side_effects(), callee_type);
}
inline ThrowCompletionOr<void> throw_if_needed_for_call(Interpreter& interpreter, Value callee, Op::CallType call_type, Optional<StringTableIndex> const& expression_string)
{
if ((call_type == Op::CallType::Call || call_type == Op::CallType::DirectEval)
&& !callee.is_function())
return throw_type_error_for_callee(interpreter, callee, "function"sv, expression_string);
if (call_type == Op::CallType::Construct && !callee.is_constructor())
return throw_type_error_for_callee(interpreter, callee, "constructor"sv, expression_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
inline Value new_function(VM& vm, FunctionNode const& function_node, Optional<IdentifierTableIndex> const& lhs_name, Optional<Operand> const& home_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
{
Value value;
if (!function_node.has_name()) {
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
Utf16FlyString name;
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 (lhs_name.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
name = vm.bytecode_interpreter().current_executable().get_identifier(lhs_name.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
value = function_node.instantiate_ordinary_function_expression(vm, name);
} else {
LibJS: Add ECMAScriptFunctionObject::create_from_function_node() helper This gives us a shared entry point for every situation where we instantiate a function based on a FunctionNode from the AST.
2025-04-07 21:08:55 +02:00
value = ECMAScriptFunctionObject::create_from_function_node(
function_node,
LibJS: Port the Identifier AST (and related) nodes to UTF-16 This eliminates quite a lot of UTF-8 / UTF-16 churn.
2025-08-06 11:12:58 -04:00
function_node.name(),
LibJS: Add ECMAScriptFunctionObject::create_from_function_node() helper This gives us a shared entry point for every situation where we instantiate a function based on a FunctionNode from the AST.
2025-04-07 21:08:55 +02:00
*vm.current_realm(),
vm.lexical_environment(),
vm.running_execution_context().private_environment);
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()) {
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 home_object_value = vm.bytecode_interpreter().get(home_object.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
static_cast<ECMAScriptFunctionObject&>(value.as_function()).set_home_object(&home_object_value.as_object());
}
return value;
}
LibJS: Rename Bytecode::Op::PropertyKind => Bytecode::PutKind This is only used to specify how a property is being added to an object by Put* instructions, so let's call it PutKind. Also add an enumeration X macro for it to prepare for upcoming specializations.
2025-10-10 11:16:02 +02: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)
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: Rename Bytecode::Op::PropertyKind => Bytecode::PutKind This is only used to specify how a property is being added to an object by Put* instructions, so let's call it PutKind. Also add an enumeration X macro for it to prepare for upcoming specializations.
2025-10-10 11:16:02 +02:00
if ((kind == PutKind::Normal || kind == PutKind::Own)
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
&& base.is_object() && property_key_value.is_int32() && property_key_value.as_i32() >= 0) {
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: 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
TRY(put_by_property_key(vm, base, base, value, base_identifier, property_key, kind));
return {};
}
struct CalleeAndThis {
Value callee;
Value this_value;
};
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<CalleeAndThis> get_callee_and_this_from_environment(Bytecode::Interpreter& interpreter, Utf16FlyString const& name, 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();
Value this_value = 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();
for (size_t i = 0; i < cache.hops; ++i)
environment = environment->outer_environment();
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));
this_value = js_undefined();
if (auto base_object = environment->with_base_object())
this_value = base_object;
return CalleeAndThis {
.callee = callee,
.this_value = this_value,
};
}
cache = {};
}
auto reference = TRY(vm.resolve_binding(name));
if (reference.environment_coordinate().has_value())
cache = reference.environment_coordinate().value();
callee = TRY(reference.get_value(vm));
if (reference.is_property_reference()) {
this_value = reference.get_this_value();
} else {
if (reference.is_environment_reference()) {
if (auto base_object = reference.base_environment().with_base_object(); base_object != nullptr)
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: Port RegExp flags and patterns to UTF-16
2025-08-06 11:28:18 -04:00
inline Value new_regexp(VM& vm, ParsedRegex const& parsed_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();
LibJS: Use FlyString in PropertyKey instead of DeprecatedFlyString This required dealing with *substantial* fallout.
2025-03-18 18:08:02 -05:00
Regex<ECMA262> regex(parsed_regex.regex, parsed_regex.pattern.to_byte_string(), parsed_regex.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
// NOTE: We bypass RegExpCreate and subsequently RegExpAlloc as an optimization to use the already parsed values.
LibJS: Port RegExp flags and patterns to UTF-16
2025-08-06 11:28:18 -04:00
auto regexp_object = RegExpObject::create(realm, move(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.
if (TRY(vm.lexical_environment()->has_binding(name)))
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
}
inline ThrowCompletionOr<ECMAScriptFunctionObject*> new_class(VM& vm, Value super_class, ClassExpression const& class_expression, Optional<IdentifierTableIndex> const& lhs_name, ReadonlySpan<Value> element_keys)
{
auto& interpreter = vm.bytecode_interpreter();
// NOTE: NewClass expects classEnv to be active lexical environment
auto* class_environment = vm.lexical_environment();
vm.running_execution_context().lexical_environment = vm.running_execution_context().saved_lexical_environments.take_last();
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
Optional<Utf16FlyString> binding_name;
Utf16FlyString class_name;
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 (!class_expression.has_name() && lhs_name.has_value()) {
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
class_name = interpreter.get_identifier(lhs_name.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
} else {
LibJS: Port the Identifier AST (and related) nodes to UTF-16 This eliminates quite a lot of UTF-8 / UTF-16 churn.
2025-08-06 11:12:58 -04:00
class_name = class_expression.name();
binding_name = class_name;
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 TRY(class_expression.create_class_constructor(vm, class_environment, vm.lexical_environment(), super_class, element_keys, binding_name, class_name));
}
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 {};
}
inline ThrowCompletionOr<Value> delete_by_id(Bytecode::Interpreter& interpreter, Value base, IdentifierTableIndex property)
{
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& identifier = interpreter.get_identifier(property);
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
bool strict = vm.in_strict_mode();
auto reference = Reference { base, identifier, {}, strict };
return TRY(reference.delete_(vm));
}
inline ThrowCompletionOr<Value> delete_by_value(Bytecode::Interpreter& interpreter, Value base, Value property_key_value)
{
auto& vm = interpreter.vm();
auto property_key = TRY(property_key_value.to_property_key(vm));
bool strict = vm.in_strict_mode();
auto reference = Reference { base, property_key, {}, strict };
return Value(TRY(reference.delete_(vm)));
}
inline ThrowCompletionOr<Value> delete_by_value_with_this(Bytecode::Interpreter& interpreter, Value base, Value property_key_value, Value this_value)
{
auto& vm = interpreter.vm();
auto property_key = TRY(property_key_value.to_property_key(vm));
bool strict = vm.in_strict_mode();
auto reference = Reference { base, property_key, this_value, strict };
return Value(TRY(reference.delete_(vm)));
}
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: 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
BuiltinIterator* as_builtin_iterator_if_next_is_not_redefined(IteratorRecord const&) 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);
}
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: 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
inline ThrowCompletionOr<Value> 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: Reduce number of proxy traps called during for..in iteration Before this change, we would enumerate all the keys with [[OwnPropertyKeys]], and then do [[GetOwnPropertyDescriptor]] twice for each key as we went through them. We now only do one [[GetOwnPropertyDescriptor]] per key, which drastically reduces the number of proxy traps when those are involved. The new trap sequence matches what you get with V8, so I don't think anyone will be unpleasantly surprised here.
2025-03-20 13:19:28 -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
return vm.heap().allocate<IteratorRecord>(iterator, js_undefined(), 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
}
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 {
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
static void dump_object(Object& o, HashTable<Object const*>& seen, int indent = 0)
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
if (seen.contains(&o))
return;
seen.set(&o);
for (auto& it : o.shape().property_table()) {
auto value = o.get_direct(it.value.offset);
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
dbgln("{} {} -> {}", String::repeated(' ', indent).release_value(), it.key.to_string(), 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
if (value.is_object()) {
dump_object(value.as_object(), seen, indent + 2);
}
}
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 Dump::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 value = interpreter.get(m_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
dbgln("(DUMP) {}: {}", m_text, value);
if (value.is_object()) {
HashTable<Object const*> seen;
dump_object(value.as_object(), seen);
}
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_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
#define JS_DEFINE_TO_BYTE_STRING_FOR_COMMON_BINARY_OP(OpTitleCase, op_snake_case) \
ByteString OpTitleCase::to_byte_string_impl(Bytecode::Executable const& executable) const \
{ \
return ByteString::formatted(#OpTitleCase " {}, {}, {}", \
format_operand("dst"sv, m_dst, executable), \
format_operand("lhs"sv, m_lhs, executable), \
format_operand("rhs"sv, m_rhs, executable)); \
}
JS_ENUMERATE_COMMON_BINARY_OPS_WITHOUT_FAST_PATH(JS_DEFINE_EXECUTE_FOR_COMMON_BINARY_OP)
JS_ENUMERATE_COMMON_BINARY_OPS_WITHOUT_FAST_PATH(JS_DEFINE_TO_BYTE_STRING_FOR_COMMON_BINARY_OP)
JS_ENUMERATE_COMMON_BINARY_OPS_WITH_FAST_PATH(JS_DEFINE_TO_BYTE_STRING_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
if (lhs.is_number() && rhs.is_number()) {
if (lhs.is_int32() && rhs.is_int32()) {
if (!Checked<i32>::addition_would_overflow(lhs.as_i32(), rhs.as_i32())) {
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
if (lhs.is_number() && rhs.is_number()) {
if (lhs.is_int32() && rhs.is_int32()) {
if (!Checked<i32>::multiplication_would_overflow(lhs.as_i32(), rhs.as_i32())) {
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(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 {};
}
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
if (lhs.is_number() && rhs.is_number()) {
if (lhs.is_int32() && rhs.is_int32()) {
LibJS+AK: Fix integer overflow UB on (any Int32 - -2147483648) It wasn't safe to use addition_would_overflow(a, -b) to check if subtraction (a - b) would overflow, since it doesn't cover this case. I don't know why we didn't have subtraction_would_overflow(), so this patch adds it. :^)
2024-05-18 10:58:11 +02:00
if (!Checked<i32>::subtraction_would_overflow(lhs.as_i32(), rhs.as_i32())) {
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 {};
}
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/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_number() && rhs.is_number()) {
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/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_number() && rhs.is_number()) {
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/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_number() && rhs.is_number()) {
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/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_number() && rhs.is_number()) {
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
static ThrowCompletionOr<Value> not_(VM&, Value value)
{
return Value(!value.to_boolean());
}
static ThrowCompletionOr<Value> typeof_(VM& vm, Value value)
{
LibJS: Rename Value::typeof() to Value::typeof_() This to avoid clashing with the GCC typeof extension, which apparently confuses clang-format.
2024-07-23 10:25:06 +02:00
return 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
}
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 {}; \
} \
ByteString OpTitleCase::to_byte_string_impl(Bytecode::Executable const& executable) const \
{ \
return ByteString::formatted(#OpTitleCase " {}, {}", \
format_operand("dst"sv, dst(), executable), \
format_operand("src"sv, src(), executable)); \
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
{
auto array = MUST(Array::create(interpreter.realm(), 0));
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
{
auto array = MUST(Array::create(interpreter.realm(), 0));
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
}
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
{
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(iterator_to_array(interpreter.vm(), interpreter.get(iterator()))));
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();
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
}
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
}
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_NEW_BUILTIN_ERROR_OP(ErrorName) \
void New##ErrorName::execute_impl(Bytecode::Interpreter& interpreter) const \
{ \
auto& vm = interpreter.vm(); \
auto& realm = *vm.current_realm(); \
interpreter.set(dst(), ErrorName::create(realm, interpreter.current_executable().get_string(m_error_string))); \
} \
ByteString New##ErrorName::to_byte_string_impl(Bytecode::Executable const& executable) const \
{ \
return ByteString::formatted("New" #ErrorName " {}, {}", \
format_operand("dst"sv, m_dst, executable), \
executable.string_table->get(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
}
JS_ENUMERATE_NEW_BUILTIN_ERROR_OPS(JS_DEFINE_NEW_BUILTIN_ERROR_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> 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: 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> ConcatString::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 string = TRY(interpreter.get(src()).to_primitive_string(vm));
interpreter.set(dst(), PrimitiveString::create(vm, interpreter.get(dst()).as_string(), string));
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
enum class BindingIsKnownToBeInitialized {
No,
Yes,
};
template<BindingIsKnownToBeInitialized binding_is_known_to_be_initialized>
static ThrowCompletionOr<void> get_binding(Interpreter& interpreter, Operand dst, IdentifierTableIndex identifier, 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: 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
for (size_t i = 0; i < cache.hops; ++i)
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: 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: 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: 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
auto reference = TRY(vm.resolve_binding(executable.get_identifier(identifier)));
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();
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
{
return get_binding<BindingIsKnownToBeInitialized::No>(interpreter, m_dst, m_identifier, m_cache);
}
ThrowCompletionOr<void> GetInitializedBinding::execute_impl(Bytecode::Interpreter& interpreter) const
{
return get_binding<BindingIsKnownToBeInitialized::Yes>(interpreter, m_dst, m_identifier, 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
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/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
{
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_global(interpreter, m_identifier, interpreter.current_executable().global_variable_caches[m_cache_index])));
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();
auto& cache = interpreter.current_executable().global_variable_caches[m_cache_index];
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: 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
if (&shape == cache.entries[0].shape) {
auto value = binding_object.get_direct(cache.entries[0].property_offset.value());
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: 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
binding_object.put_direct(cache.entries[0].property_offset.value(), 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>>();
TRY((*module)->environment()->set_mutable_binding_direct(vm, cache.environment_binding_index, src, vm.in_strict_mode()));
} else {
TRY(declarative_record.set_mutable_binding_direct(vm, cache.environment_binding_index, src, vm.in_strict_mode()));
}
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;
return TRY(module_environment.set_mutable_binding_direct(vm, index.value(), src, vm.in_strict_mode()));
}
return TRY(module_environment.set_mutable_binding(vm, identifier, src, vm.in_strict_mode()));
}
}
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;
TRY(declarative_record.set_mutable_binding(vm, identifier, src, vm.in_strict_mode()));
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));
if (!success && vm.in_strict_mode()) {
// 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: 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 {};
}
auto reference = TRY(vm.resolve_binding(identifier, &declarative_record));
TRY(reference.put_value(vm, src));
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> 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: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
auto reference = TRY(vm.resolve_binding(string));
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
{
auto make_and_swap_envs = [&](auto& old_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
auto declarative_environment = new_declarative_environment(*old_environment).ptr();
declarative_environment->ensure_capacity(m_capacity);
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
GC::Ptr<Environment> environment = declarative_environment;
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
swap(old_environment, environment);
return environment;
};
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: 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
running_execution_context.saved_lexical_environments.append(make_and_swap_envs(running_execution_context.lexical_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;
}
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> 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/JIT: Support the EnterObjectEnvironment bytecode instruction We can now use `with` statements in jitted code. :^)
2023-11-12 00:12:21 +01:00
interpreter.enter_object_environment(*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: 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 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
void LeaveFinally::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Cleanup unwind state when transferring control out of a finalizer This does two things: * Clear exceptions when transferring control out of a finalizer Otherwise they would resurface at the end of the next finalizer (see test the new test case), or at the end of a function * Pop one scheduled jump when transferring control out of a finalizer This removes one old FIXME
2024-04-11 11:58:18 +02:00
{
interpreter.leave_finally();
}
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 RestoreScheduledJump::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Restore scheduled jumps in catch blocks without finalizers
2024-04-11 11:07:35 +02:00
{
interpreter.restore_scheduled_jump();
}
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;
if (m_kind == Kind::Mapped) {
arguments_object = create_mapped_arguments_object(interpreter.vm(), *function, function->formal_parameters(), passed_arguments, *environment);
} 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>
static ThrowCompletionOr<void> initialize_or_set_binding(Interpreter& interpreter, IdentifierTableIndex identifier_index, 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/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
for (size_t i = 0; i < cache.hops; ++i)
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: 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 {
TRY(static_cast<DeclarativeEnvironment&>(*environment).set_mutable_binding_direct(vm, cache.index, value, vm.in_strict_mode()));
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/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: 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 reference = TRY(vm.resolve_binding(interpreter.get_identifier(identifier_index), 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
{
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 initialize_or_set_binding<EnvironmentMode::Lexical, BindingInitializationMode::Initialize>(interpreter, m_identifier, 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
{
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 initialize_or_set_binding<EnvironmentMode::Var, BindingInitializationMode::Initialize>(interpreter, m_identifier, 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
{
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 initialize_or_set_binding<EnvironmentMode::Lexical, BindingInitializationMode::Set>(interpreter, m_identifier, 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
{
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 initialize_or_set_binding<EnvironmentMode::Var, BindingInitializationMode::Set>(interpreter, m_identifier, 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/JIT: Resolve the PropertyLookupCache pointers at JIT time We know where the lookup cache is by the time we're jitting code, so let's put the pointer directly into the instruction stream.
2023-11-05 14:33:54 +01:00
auto& cache = interpreter.current_executable().property_lookup_caches[m_cache_index];
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
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_id(interpreter.vm(), m_base_identifier, m_property, base_value, base_value, cache, interpreter.current_executable())));
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/JIT: Resolve the PropertyLookupCache pointers at JIT time We know where the lookup cache is by the time we're jitting code, so let's put the pointer directly into the instruction stream.
2023-11-05 14:33:54 +01:00
auto& cache = interpreter.current_executable().property_lookup_caches[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(), TRY(get_by_id(interpreter.vm(), {}, m_property, base_value, this_value, cache, interpreter.current_executable())));
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();
auto& cache = executable.property_lookup_caches[m_cache_index];
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
interpreter.set(dst(), TRY(get_by_id<GetByIdMode::Length>(interpreter.vm(), m_base_identifier, *executable.length_identifier, base_value, base_value, cache, executable)));
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();
auto& cache = executable.property_lookup_caches[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(), TRY(get_by_id<GetByIdMode::Length>(interpreter.vm(), {}, *executable.length_identifier, base_value, this_value, cache, executable)));
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/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
if (!base.is_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 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 {};
}
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> PutById::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 base = interpreter.get(m_base);
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 base_identifier = interpreter.get_identifier(m_base_identifier);
PropertyKey name { interpreter.get_identifier(m_property), PropertyKey::StringMayBeNumber::No };
LibJS: Add PutByNumericId and change PutById to be string key only Previously, PutById constructed a PropertyKey from the identifier, which coerced numeric-like strings to numbers. This moves that decision to bytecode generation: the bytecode generator now emits PutByNumericId for numeric keys and PutById for string keys. This removes per-execution parsing from the interpreter. 1.4x speedup on the following microbenchmark: ```js const o = {}; for (let i = 0; i < 10_000_000; i++) { o.a = 1; o.b = 2; o.c = 3; } ```
2025-09-13 16:20:41 +02:00
auto& cache = interpreter.current_executable().property_lookup_caches[m_cache_index];
TRY(put_by_property_key(vm, base, base, value, base_identifier, name, m_kind, &cache));
return {};
}
ThrowCompletionOr<void> PutByNumericId::execute_impl(Bytecode::Interpreter& interpreter) const
{
auto& vm = interpreter.vm();
auto value = interpreter.get(m_src);
auto base = interpreter.get(m_base);
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 base_identifier = interpreter.get_identifier(m_base_identifier);
LibJS: Add PutByNumericId and change PutById to be string key only Previously, PutById constructed a PropertyKey from the identifier, which coerced numeric-like strings to numbers. This moves that decision to bytecode generation: the bytecode generator now emits PutByNumericId for numeric keys and PutById for string keys. This removes per-execution parsing from the interpreter. 1.4x speedup on the following microbenchmark: ```js const o = {}; for (let i = 0; i < 10_000_000; i++) { o.a = 1; o.b = 2; o.c = 3; } ```
2025-09-13 16:20:41 +02:00
PropertyKey name { m_property_index };
LibJS: Add basic monomorphic caching for PutById property access This patch makes it possible for JS::Object::internal_set() to populate a CacheablePropertyMetadata, and uses this to implement a basic monomorphic cache for the most common form of property write access.
2023-11-08 20:51:26 +01:00
auto& cache = interpreter.current_executable().property_lookup_caches[m_cache_index];
LibJS: Include identifier information in nullish property write access When a PutById / PutByValue 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 = 1 Uncaught exception: [TypeError] Cannot access property "bar" on null object "foo" at <unknown> > foo = { bar: undefined } > foo.bar.baz = 1 Uncaught exception: [TypeError] Cannot access property "baz" on undefined object "foo.bar" at <unknown> Note we certainly don't capture all possible nullish property write accesses here. This just covers cases I've seen most on live websites; we can cover more cases as they arise.
2024-03-29 12:10:52 -04:00
TRY(put_by_property_key(vm, base, base, value, base_identifier, name, m_kind, &cache));
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> PutByIdWithThis::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 base = interpreter.get(m_base);
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
PropertyKey name { interpreter.get_identifier(m_property), PropertyKey::StringMayBeNumber::No };
LibJS: Add basic monomorphic caching for PutById property access This patch makes it possible for JS::Object::internal_set() to populate a CacheablePropertyMetadata, and uses this to implement a basic monomorphic cache for the most common form of property write access.
2023-11-08 20:51:26 +01:00
auto& cache = interpreter.current_executable().property_lookup_caches[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
TRY(put_by_property_key(vm, base, interpreter.get(m_this_value), value, {}, name, m_kind, &cache));
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> 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: 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 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 {};
}
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> 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
{
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);
interpreter.set(dst(), TRY(Bytecode::delete_by_id(interpreter, base_value, 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
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> DeleteByIdWithThis::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_value = interpreter.get(m_base);
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& identifier = 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
bool strict = vm.in_strict_mode();
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 reference = Reference { base_value, identifier, interpreter.get(m_this_value), strict };
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
}
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:
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 TRY(MathObject::abs_impl(interpreter.vm(), interpreter.get(arguments[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:
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 TRY(MathObject::log_impl(interpreter.vm(), interpreter.get(arguments[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:
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 TRY(MathObject::pow_impl(interpreter.vm(), interpreter.get(arguments[0]), interpreter.get(arguments[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:
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 TRY(MathObject::exp_impl(interpreter.vm(), interpreter.get(arguments[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:
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 TRY(MathObject::ceil_impl(interpreter.vm(), interpreter.get(arguments[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:
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 TRY(MathObject::floor_impl(interpreter.vm(), interpreter.get(arguments[0])));
LibJS: Add builtin for Math.imul()
2025-04-03 11:58:30 +02:00
case Builtin::MathImul:
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 TRY(MathObject::imul_impl(interpreter.vm(), interpreter.get(arguments[0]), interpreter.get(arguments[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:
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 TRY(MathObject::round_impl(interpreter.vm(), interpreter.get(arguments[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:
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 TRY(MathObject::sqrt_impl(interpreter.vm(), interpreter.get(arguments[0])));
LibJS: Use CallBuiltin for Math.sin() Improves performance on https://pierre.co/
2025-05-26 13:54:46 +03:00
case Builtin::MathSin:
return TRY(MathObject::sin_impl(interpreter.vm(), interpreter.get(arguments[0])));
LibJS: Use CallBuiltin for Math.cos()
2025-05-26 14:03:37 +03:00
case Builtin::MathCos:
return TRY(MathObject::cos_impl(interpreter.vm(), interpreter.get(arguments[0])));
LibJS: Use CallBuiltin for Math.tan()
2025-05-26 14:07:59 +03:00
case Builtin::MathTan:
return TRY(MathObject::tan_impl(interpreter.vm(), interpreter.get(arguments[0])));
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: 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();
}
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
template<CallType call_type>
static ThrowCompletionOr<void> execute_call(
Bytecode::Interpreter& interpreter,
Value callee,
Value this_value,
ReadonlySpan<Operand> arguments,
Operand dst,
Optional<StringTableIndex> const& expression_string)
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 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
TRY(throw_if_needed_for_call(interpreter, callee, call_type, expression_string));
LibJS: Let invokers (callers) of [[Call]] allocate ExecutionContext Instead of letting every [[Call]] implementation allocate an ExecutionContext, we now make that a responsibility of the caller. The main point of this exercise is to allow the Call instruction to write function arguments directly into the callee ExecutionContext instead of copying them later. This makes function calls significantly faster: - 10-20% faster on micro-benchmarks (depending on argument count) - 4% speedup on Kraken - 2% speedup on Octane - 5% speedup on JetStream
2025-04-27 11:53:11 +02:00
auto& function = callee.as_function();
ExecutionContext* callee_context = nullptr;
size_t registers_and_constants_and_locals_count = 0;
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
size_t argument_count = arguments.size();
LibJS: Let invokers (callers) of [[Call]] allocate ExecutionContext Instead of letting every [[Call]] implementation allocate an ExecutionContext, we now make that a responsibility of the caller. The main point of this exercise is to allow the Call instruction to write function arguments directly into the callee ExecutionContext instead of copying them later. This makes function calls significantly faster: - 10-20% faster on micro-benchmarks (depending on argument count) - 4% speedup on Kraken - 2% speedup on Octane - 5% speedup on JetStream
2025-04-27 11:53:11 +02:00
TRY(function.get_stack_frame_size(registers_and_constants_and_locals_count, argument_count));
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
ALLOCATE_EXECUTION_CONTEXT_ON_NATIVE_STACK_WITHOUT_CLEARING_ARGS(callee_context, registers_and_constants_and_locals_count, max(arguments.size(), argument_count));
LibJS: Let invokers (callers) of [[Call]] allocate ExecutionContext Instead of letting every [[Call]] implementation allocate an ExecutionContext, we now make that a responsibility of the caller. The main point of this exercise is to allow the Call instruction to write function arguments directly into the callee ExecutionContext instead of copying them later. This makes function calls significantly faster: - 10-20% faster on micro-benchmarks (depending on argument count) - 4% speedup on Kraken - 2% speedup on Octane - 5% speedup on JetStream
2025-04-27 11:53:11 +02:00
auto* callee_context_argument_values = callee_context->arguments.data();
auto const callee_context_argument_count = callee_context->arguments.size();
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
auto const insn_argument_count = arguments.size();
LibJS: Let invokers (callers) of [[Call]] allocate ExecutionContext Instead of letting every [[Call]] implementation allocate an ExecutionContext, we now make that a responsibility of the caller. The main point of this exercise is to allow the Call instruction to write function arguments directly into the callee ExecutionContext instead of copying them later. This makes function calls significantly faster: - 10-20% faster on micro-benchmarks (depending on argument count) - 4% speedup on Kraken - 2% speedup on Octane - 5% speedup on JetStream
2025-04-27 11:53:11 +02:00
for (size_t i = 0; i < insn_argument_count; ++i)
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
callee_context_argument_values[i] = interpreter.get(arguments[i]);
LibJS: Let invokers (callers) of [[Call]] allocate ExecutionContext Instead of letting every [[Call]] implementation allocate an ExecutionContext, we now make that a responsibility of the caller. The main point of this exercise is to allow the Call instruction to write function arguments directly into the callee ExecutionContext instead of copying them later. This makes function calls significantly faster: - 10-20% faster on micro-benchmarks (depending on argument count) - 4% speedup on Kraken - 2% speedup on Octane - 5% speedup on JetStream
2025-04-27 11:53:11 +02: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;
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
Value retval;
if (call_type == CallType::DirectEval && callee == interpreter.realm().intrinsics().eval_function()) {
retval = TRY(perform_eval(interpreter.vm(), !callee_context->arguments.is_empty() ? callee_context->arguments[0] : js_undefined(), interpreter.vm().in_strict_mode() ? CallerMode::Strict : CallerMode::NonStrict, EvalMode::Direct));
} 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 {};
}
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
{
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
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);
}
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
{
return execute_call<CallType::Construct>(interpreter, interpreter.get(m_callee), js_undefined(), { m_arguments, m_argument_count }, m_dst, m_expression_string);
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
{
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
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);
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
if (m_argument_count == Bytecode::builtin_argument_count(m_builtin) && callee.is_object() && interpreter.realm().get_builtin_value(m_builtin) == &callee.as_object()) {
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 {};
}
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
return execute_call<CallType::Call>(interpreter, callee, interpreter.get(m_this_value), { m_arguments, m_argument_count }, m_dst, m_expression_string);
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>
static ThrowCompletionOr<void> call_with_argument_array(
Bytecode::Interpreter& interpreter,
Value callee,
Value this_value,
Value arguments,
Operand dst,
Optional<StringTableIndex> const& expression_string)
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));
auto& function = callee.as_function();
auto& argument_array = arguments.as_array();
auto argument_array_length = argument_array.indexed_properties().array_like_size();
ExecutionContext* callee_context = nullptr;
size_t argument_count = argument_array_length;
size_t registers_and_constants_and_locals_count = 0;
TRY(function.get_stack_frame_size(registers_and_constants_and_locals_count, argument_count));
ALLOCATE_EXECUTION_CONTEXT_ON_NATIVE_STACK_WITHOUT_CLEARING_ARGS(callee_context, registers_and_constants_and_locals_count, max(argument_array_length, argument_count));
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()) {
auto& vm = interpreter.vm();
retval = TRY(perform_eval(vm, !callee_context->arguments.is_empty() ? callee_context->arguments[0] : js_undefined(), vm.in_strict_mode() ? CallerMode::Strict : CallerMode::NonStrict, EvalMode::Direct));
} 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
{
return call_with_argument_array<CallType::Call>(interpreter, interpreter.get(callee()), interpreter.get(this_value()), interpreter.get(arguments()), dst(), expression_string());
}
ThrowCompletionOr<void> CallDirectEvalWithArgumentArray::execute_impl(Bytecode::Interpreter& interpreter) const
{
return call_with_argument_array<CallType::DirectEval>(interpreter, interpreter.get(callee()), interpreter.get(this_value()), interpreter.get(arguments()), dst(), expression_string());
}
ThrowCompletionOr<void> CallConstructWithArgumentArray::execute_impl(Bytecode::Interpreter& interpreter) const
{
return call_with_argument_array<CallType::Construct>(interpreter, interpreter.get(callee()), js_undefined(), interpreter.get(arguments()), dst(), expression_string());
}
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.
if (!Value(func).is_constructor())
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();
}
ExecutionContext* callee_context = nullptr;
size_t argument_count = argument_array_length;
size_t registers_and_constants_and_locals_count = 0;
TRY(function.get_stack_frame_size(registers_and_constants_and_locals_count, argument_count));
ALLOCATE_EXECUTION_CONTEXT_ON_NATIVE_STACK_WITHOUT_CLEARING_ARGS(callee_context, registers_and_constants_and_locals_count, max(argument_array_length, argument_count));
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]].
auto& f = this_environment.function_object();
// 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
{
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();
interpreter.set(dst(), new_function(vm, m_function_node, m_lhs_name, 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.
if (old_value.is_int32()) {
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.
if (old_value.is_int32()) {
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 {};
}
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> 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/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
if (!src.is_object())
return vm.throw_completion<TypeError>(ErrorType::NotAnObject, src.to_string_without_side_effects());
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: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
if (value.is_nullish())
return vm.throw_completion<TypeError>(ErrorType::NotObjectCoercible, value.to_string_without_side_effects());
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: 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 (value.is_special_empty_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 vm.throw_completion<ReferenceError>(ErrorType::BindingNotInitialized, value.to_string_without_side_effects());
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 LeaveLexicalEnvironment::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: Cache the running execution context in interpreter
2024-05-11 18:16:27 +02:00
auto& running_execution_context = interpreter.running_execution_context();
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
running_execution_context.lexical_environment = running_execution_context.saved_lexical_environments.take_last();
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 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 LeaveUnwindContext::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
{
interpreter.leave_unwind_context();
}
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 PrepareYield::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Prepare yield object before re-routing it through finally
2024-05-18 17:25:43 +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 value = interpreter.get(m_value).is_special_empty_value() ? js_undefined() : interpreter.get(m_value);
interpreter.set(m_dest, interpreter.do_yield(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
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 {};
}
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> PutByValue::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: 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 base_identifier = interpreter.get_identifier(m_base_identifier);
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
TRY(put_by_value(vm, interpreter.get(m_base), base_identifier, interpreter.get(m_property), value, m_kind));
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> PutByValueWithThis::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 base = interpreter.get(m_base);
auto property_key = TRY(interpreter.get(m_property).to_property_key(vm));
TRY(put_by_property_key(vm, base, interpreter.get(m_this_value), value, {}, property_key, m_kind));
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> 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
{
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 property_key_value = interpreter.get(m_property);
interpreter.set(dst(), TRY(delete_by_value(interpreter, base_value, property_key_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> DeleteByValueWithThis::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 property_key_value = interpreter.get(m_property);
auto base_value = interpreter.get(m_base);
auto this_value = interpreter.get(m_this_value);
interpreter.set(dst(), TRY(delete_by_value_with_this(interpreter, base_value, property_key_value, this_value)));
LibJS/JIT: Compile the DeleteByValueWithThis instruction
2023-10-29 21:37:52 +01:00
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();
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_iterator(vm, interpreter.get(iterable()), m_hint)));
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
void GetObjectFromIteratorRecord::execute_impl(Bytecode::Interpreter& interpreter) const
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
{
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& iterator_record = static_cast<IteratorRecord&>(interpreter.get(m_iterator_record).as_cell());
interpreter.set(m_object, iterator_record.iterator);
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
}
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 GetNextMethodFromIteratorRecord::execute_impl(Bytecode::Interpreter& interpreter) const
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
{
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& iterator_record = static_cast<IteratorRecord&>(interpreter.get(m_iterator_record).as_cell());
interpreter.set(m_next_method, iterator_record.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
}
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: 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_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 method = TRY(interpreter.get(m_object).get_method(vm, identifier));
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 {};
}
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> 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: 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_record = TRY(get_object_property_iterator(interpreter, interpreter.get(object())));
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(), iterator_record);
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();
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& iterator = static_cast<IteratorRecord&>(interpreter.get(m_iterator_record).as_cell());
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
// FIXME: Return the value of the resulting completion. (Note that m_completion_value can be empty!)
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
TRY(iterator_close(vm, iterator, Completion { m_completion_type, m_completion_value.value_or(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 {};
}
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> AsyncIteratorClose::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& iterator = static_cast<IteratorRecord&>(interpreter.get(m_iterator_record).as_cell());
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
// FIXME: Return the value of the resulting completion. (Note that m_completion_value can be empty!)
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
TRY(async_iterator_close(vm, iterator, Completion { m_completion_type, m_completion_value.value_or(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 {};
}
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();
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& iterator_record = static_cast<IteratorRecord&>(interpreter.get(m_iterator_record).as_cell());
interpreter.set(dst(), TRY(iterator_next(vm, iterator_record)));
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();
auto& iterator_record = static_cast<IteratorRecord&>(interpreter.get(m_iterator_record).as_cell());
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));
if (iteration_result_or_done.has<IterationDone>()) {
interpreter.set(dst_done(), Value(true));
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>();
interpreter.set(dst_done(), TRY(iteration_result.done));
interpreter.set(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 {};
}
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> 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;
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: 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
element_keys.append(element_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(), TRY(new_class(interpreter.vm(), super_class, m_class_expression, m_lhs_name, element_keys)));
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();
for (size_t i = 0; i < m_cache.hops; ++i)
environment = environment->outer_environment();
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 {};
}
m_cache = {};
}
// 1. Let val be the result of evaluating UnaryExpression.
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 reference = TRY(vm.resolve_binding(interpreter.get_identifier(m_identifier)));
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 BlockDeclarationInstantiation::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: Cache the running execution context in interpreter
2024-05-11 18:16:27 +02:00
auto old_environment = interpreter.running_execution_context().lexical_environment;
auto& running_execution_context = interpreter.running_execution_context();
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
running_execution_context.saved_lexical_environments.append(old_environment);
running_execution_context.lexical_environment = new_declarative_environment(*old_environment);
m_scope_node.block_declaration_instantiation(vm, running_execution_context.lexical_environment);
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
ByteString Mov::to_byte_string_impl(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
{
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 ByteString::formatted("Mov {}, {}",
format_operand("dst"sv, m_dst, executable),
format_operand("src"sv, m_src, executable));
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
ByteString NewArray::to_byte_string_impl(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
{
StringBuilder builder;
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
builder.appendff("NewArray {}", format_operand("dst"sv, dst(), executable));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
if (m_element_count != 0) {
LibJS/Bytecode: Make NewArray a variable-length instruction This removes a layer of indirection in the bytecode where we had to make sure all the initializer elements were laid out in sequential registers. Array expressions no longer clobber registers permanently, and they can be reused immediately afterwards.
2024-05-08 12:43:08 +02:00
builder.appendff(", {}", format_operand_list("args"sv, { m_elements, m_element_count }, executable));
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
return builder.to_byte_string();
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
ByteString NewPrimitiveArray::to_byte_string_impl(Bytecode::Executable const& executable) 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
{
Everywhere: Remove `sv` suffix from format string literals This prevents the compile-time checks that would catch errors in the format invocation (which would usually lead to a runtime crash).
2025-04-08 13:50:50 -04:00
return ByteString::formatted("NewPrimitiveArray {}, {}",
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
format_operand("dst"sv, dst(), executable),
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
format_value_list("elements"sv, elements()));
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: 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
ByteString AddPrivateName::to_byte_string_impl(Bytecode::Executable const& executable) const
{
Everywhere: Remove `sv` suffix from format string literals This prevents the compile-time checks that would catch errors in the format invocation (which would usually lead to a runtime crash).
2025-04-08 13:50:50 -04:00
return ByteString::formatted("AddPrivateName {}", executable.identifier_table->get(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
}
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
ByteString ArrayAppend::to_byte_string_impl(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
{
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 ByteString::formatted("Append {}, {}{}",
format_operand("dst"sv, dst(), executable),
format_operand("src"sv, src(), executable),
m_is_spread ? " **"sv : ""sv);
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
ByteString IteratorToArray::to_byte_string_impl(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
{
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 ByteString::formatted("IteratorToArray {}, {}",
format_operand("dst"sv, dst(), executable),
format_operand("iterator"sv, iterator(), executable));
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
ByteString NewObject::to_byte_string_impl(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
{
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 ByteString::formatted("NewObject {}", format_operand("dst"sv, dst(), executable));
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 NewRegExp::to_byte_string_impl(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
{
LibJS: Make Optional<StringTableIndex> use less space We can use the index's invalid state to signal an empty optional. This makes Optional<StringTableIndex> 4 bytes instead of 8, shrinking every bytecode instruction that uses these.
2025-04-05 21:46:37 +02:00
return ByteString::formatted("NewRegExp {}, source:\"{}\" flags:\"{}\"",
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
format_operand("dst"sv, dst(), executable),
LibJS: Make Optional<StringTableIndex> use less space We can use the index's invalid state to signal an empty optional. This makes Optional<StringTableIndex> 4 bytes instead of 8, shrinking every bytecode instruction that uses these.
2025-04-05 21:46:37 +02:00
executable.get_string(m_source_index),
executable.get_string(m_flags_index));
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
ByteString CopyObjectExcludingProperties::to_byte_string_impl(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
{
StringBuilder builder;
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
builder.appendff("CopyObjectExcludingProperties {}, {}",
format_operand("dst"sv, dst(), executable),
format_operand("from"sv, m_from_object, executable));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
if (m_excluded_names_count != 0) {
builder.append(" excluding:["sv);
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
for (size_t i = 0; i < m_excluded_names_count; ++i) {
if (i != 0)
builder.append(", "sv);
builder.append(format_operand("#"sv, m_excluded_names[i], executable));
}
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
builder.append(']');
}
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 builder.to_byte_string();
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
ByteString ConcatString::to_byte_string_impl(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
{
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 ByteString::formatted("ConcatString {}, {}",
format_operand("dst"sv, dst(), executable),
format_operand("src"sv, src(), executable));
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 GetCalleeAndThisFromEnvironment::to_byte_string_impl(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
{
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 ByteString::formatted("GetCalleeAndThisFromEnvironment {}, {} <- {}",
format_operand("callee"sv, m_callee, executable),
format_operand("this"sv, m_this_value, executable),
executable.identifier_table->get(m_identifier));
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: Rename GetVariable => GetBinding
2024-05-14 11:32:04 +02:00
ByteString GetBinding::to_byte_string_impl(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
{
LibJS/Bytecode: Rename GetVariable => GetBinding
2024-05-14 11:32:04 +02:00
return ByteString::formatted("GetBinding {}, {}",
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
format_operand("dst"sv, dst(), executable),
executable.identifier_table->get(m_identifier));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02: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
ByteString GetInitializedBinding::to_byte_string_impl(Bytecode::Executable const& executable) const
{
return ByteString::formatted("GetInitializedBinding {}, {}",
format_operand("dst"sv, dst(), executable),
executable.identifier_table->get(m_identifier));
}
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 GetGlobal::to_byte_string_impl(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
{
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 ByteString::formatted("GetGlobal {}, {}", format_operand("dst"sv, dst(), executable),
executable.identifier_table->get(m_identifier));
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
ByteString SetGlobal::to_byte_string_impl(Bytecode::Executable const& executable) const
{
return ByteString::formatted("SetGlobal {}, {}",
executable.identifier_table->get(m_identifier),
format_operand("src"sv, src(), executable));
}
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 DeleteVariable::to_byte_string_impl(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
{
LibJS/Bytecode: Make IdentifierTableIndex a 32-bit index This makes a bunch of instructions smaller.
2024-05-06 10:12:02 +02:00
return ByteString::formatted("DeleteVariable {}", executable.identifier_table->get(m_identifier));
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 CreateLexicalEnvironment::to_byte_string_impl(Bytecode::Executable const&) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
return "CreateLexicalEnvironment"sv;
}
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
ByteString CreatePrivateEnvironment::to_byte_string_impl(Bytecode::Executable const&) const
{
return "CreatePrivateEnvironment"sv;
}
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
ByteString CreateVariableEnvironment::to_byte_string_impl(Bytecode::Executable const&) const
{
return "CreateVariableEnvironment"sv;
}
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 CreateVariable::to_byte_string_impl(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
{
auto mode_string = m_mode == EnvironmentMode::Lexical ? "Lexical" : "Variable";
LibJS/Bytecode: Make IdentifierTableIndex a 32-bit index This makes a bunch of instructions smaller.
2024-05-06 10:12:02 +02:00
return ByteString::formatted("CreateVariable env:{} immutable:{} global:{} {}", mode_string, m_is_immutable, m_is_global, executable.identifier_table->get(m_identifier));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02: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
ByteString CreateRestParams::to_byte_string_impl(Bytecode::Executable const& executable) const
{
return ByteString::formatted("CreateRestParams {}, rest_index:{}", format_operand("dst"sv, m_dst, executable), m_rest_index);
}
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
ByteString CreateArguments::to_byte_string_impl(Bytecode::Executable const& executable) 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: 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
StringBuilder builder;
builder.appendff("CreateArguments");
if (m_dst.has_value())
builder.appendff(" {}", format_operand("dst"sv, *m_dst, executable));
builder.appendff(" {} immutable:{}", m_kind == Kind::Mapped ? "mapped"sv : "unmapped"sv, m_is_immutable);
return builder.to_byte_string();
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: 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
ByteString EnterObjectEnvironment::to_byte_string_impl(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
{
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 ByteString::formatted("EnterObjectEnvironment {}",
format_operand("object"sv, m_object, executable));
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: 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
ByteString InitializeLexicalBinding::to_byte_string_impl(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
{
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
return ByteString::formatted("InitializeLexicalBinding {}, {}",
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
executable.identifier_table->get(m_identifier),
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
format_operand("src"sv, src(), executable));
}
ByteString InitializeVariableBinding::to_byte_string_impl(Bytecode::Executable const& executable) const
{
return ByteString::formatted("InitializeVariableBinding {}, {}",
executable.identifier_table->get(m_identifier),
format_operand("src"sv, src(), executable));
}
ByteString SetLexicalBinding::to_byte_string_impl(Bytecode::Executable const& executable) const
{
return ByteString::formatted("SetLexicalBinding {}, {}",
executable.identifier_table->get(m_identifier),
format_operand("src"sv, src(), executable));
}
ByteString SetVariableBinding::to_byte_string_impl(Bytecode::Executable const& executable) const
{
return ByteString::formatted("SetVariableBinding {}, {}",
executable.identifier_table->get(m_identifier),
format_operand("src"sv, src(), executable));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
LibJS: Rename Bytecode::Op::PropertyKind => Bytecode::PutKind This is only used to specify how a property is being added to an object by Put* instructions, so let's call it PutKind. Also add an enumeration X macro for it to prepare for upcoming specializations.
2025-10-10 11:16:02 +02:00
static StringView property_kind_to_string(PutKind kind)
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
switch (kind) {
LibJS: Rename Bytecode::Op::PropertyKind => Bytecode::PutKind This is only used to specify how a property is being added to an object by Put* instructions, so let's call it PutKind. Also add an enumeration X macro for it to prepare for upcoming specializations.
2025-10-10 11:16:02 +02:00
case PutKind::Getter:
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return "getter"sv;
LibJS: Rename Bytecode::Op::PropertyKind => Bytecode::PutKind This is only used to specify how a property is being added to an object by Put* instructions, so let's call it PutKind. Also add an enumeration X macro for it to prepare for upcoming specializations.
2025-10-10 11:16:02 +02:00
case PutKind::Setter:
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return "setter"sv;
LibJS: Rename Bytecode::Op::PropertyKind => Bytecode::PutKind This is only used to specify how a property is being added to an object by Put* instructions, so let's call it PutKind. Also add an enumeration X macro for it to prepare for upcoming specializations.
2025-10-10 11:16:02 +02:00
case PutKind::Normal:
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return "key-value"sv;
LibJS: Rename Bytecode::Op::PropertyKind => Bytecode::PutKind This is only used to specify how a property is being added to an object by Put* instructions, so let's call it PutKind. Also add an enumeration X macro for it to prepare for upcoming specializations.
2025-10-10 11:16:02 +02:00
case PutKind::Own:
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return "direct-key-value"sv;
LibJS: Rename Bytecode::Op::PropertyKind => Bytecode::PutKind This is only used to specify how a property is being added to an object by Put* instructions, so let's call it PutKind. Also add an enumeration X macro for it to prepare for upcoming specializations.
2025-10-10 11:16:02 +02:00
case PutKind::Prototype:
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
return "proto-setter"sv;
}
VERIFY_NOT_REACHED();
}
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
ByteString PutBySpread::to_byte_string_impl(Bytecode::Executable const& executable) const
{
return ByteString::formatted("PutBySpread {}, {}",
format_operand("base"sv, m_base, executable),
format_operand("src"sv, m_src, executable));
}
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 PutById::to_byte_string_impl(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
{
auto kind = property_kind_to_string(m_kind);
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 ByteString::formatted("PutById {}, {}, {}, kind:{}",
format_operand("base"sv, m_base, executable),
executable.identifier_table->get(m_property),
format_operand("src"sv, m_src, executable),
kind);
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 PutByNumericId and change PutById to be string key only Previously, PutById constructed a PropertyKey from the identifier, which coerced numeric-like strings to numbers. This moves that decision to bytecode generation: the bytecode generator now emits PutByNumericId for numeric keys and PutById for string keys. This removes per-execution parsing from the interpreter. 1.4x speedup on the following microbenchmark: ```js const o = {}; for (let i = 0; i < 10_000_000; i++) { o.a = 1; o.b = 2; o.c = 3; } ```
2025-09-13 16:20:41 +02:00
ByteString PutByNumericId::to_byte_string_impl(Bytecode::Executable const& executable) const
{
auto kind = property_kind_to_string(m_kind);
return ByteString::formatted("PutByNumericId {}, {}, {}, kind:{}",
format_operand("base"sv, m_base, executable),
m_property_index,
format_operand("src"sv, m_src, executable),
kind);
}
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 PutByIdWithThis::to_byte_string_impl(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
{
auto kind = property_kind_to_string(m_kind);
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 ByteString::formatted("PutByIdWithThis {}, {}, {}, {}, kind:{}",
format_operand("base"sv, m_base, executable),
executable.identifier_table->get(m_property),
format_operand("src"sv, m_src, executable),
format_operand("this"sv, m_this_value, executable),
kind);
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 PutPrivateById::to_byte_string_impl(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
{
auto kind = property_kind_to_string(m_kind);
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 ByteString::formatted(
"PutPrivateById {}, {}, {}, kind:{} ",
format_operand("base"sv, m_base, executable),
executable.identifier_table->get(m_property),
format_operand("src"sv, m_src, executable),
kind);
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 GetById::to_byte_string_impl(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
{
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 ByteString::formatted("GetById {}, {}, {}",
format_operand("dst"sv, m_dst, executable),
format_operand("base"sv, m_base, executable),
executable.identifier_table->get(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
}
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 GetByIdWithThis::to_byte_string_impl(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
{
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 ByteString::formatted("GetByIdWithThis {}, {}, {}, {}",
format_operand("dst"sv, m_dst, executable),
format_operand("base"sv, m_base, executable),
executable.identifier_table->get(m_property),
format_operand("this"sv, m_this_value, executable));
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 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
ByteString GetLength::to_byte_string_impl(Bytecode::Executable const& executable) const
{
return ByteString::formatted("GetLength {}, {}",
format_operand("dst"sv, m_dst, executable),
format_operand("base"sv, m_base, executable));
}
ByteString GetLengthWithThis::to_byte_string_impl(Bytecode::Executable const& executable) const
{
return ByteString::formatted("GetLengthWithThis {}, {}, {}",
format_operand("dst"sv, m_dst, executable),
format_operand("base"sv, m_base, executable),
format_operand("this"sv, m_this_value, executable));
}
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 GetPrivateById::to_byte_string_impl(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
{
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 ByteString::formatted("GetPrivateById {}, {}, {}",
format_operand("dst"sv, m_dst, executable),
format_operand("base"sv, m_base, executable),
executable.identifier_table->get(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
}
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 HasPrivateId::to_byte_string_impl(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
{
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 ByteString::formatted("HasPrivateId {}, {}, {}",
format_operand("dst"sv, m_dst, executable),
format_operand("base"sv, m_base, executable),
executable.identifier_table->get(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
}
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 DeleteById::to_byte_string_impl(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
{
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 ByteString::formatted("DeleteById {}, {}, {}",
format_operand("dst"sv, m_dst, executable),
format_operand("base"sv, m_base, executable),
executable.identifier_table->get(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
}
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 DeleteByIdWithThis::to_byte_string_impl(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
{
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 ByteString::formatted("DeleteByIdWithThis {}, {}, {}, {}",
format_operand("dst"sv, m_dst, executable),
format_operand("base"sv, m_base, executable),
executable.identifier_table->get(m_property),
format_operand("this"sv, m_this_value, executable));
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 Jump::to_byte_string_impl(Bytecode::Executable const&) 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: Make each Jump instruction inherit Instruction directly Before this change, all JumpFoo instructions inherited from Jump, which forced the unconditional Jump to have an unusued "false target" member. Also, labels were unnecessarily wrapped in Optional<>. By defining each jump instruction separately, they all shrink in size, and all ambiguity is removed.
2024-05-05 11:52:14 +02:00
return ByteString::formatted("Jump {}", m_target);
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
ByteString JumpIf::to_byte_string_impl(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
{
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 ByteString::formatted("JumpIf {}, \033[32mtrue\033[0m:{} \033[32mfalse\033[0m:{}",
format_operand("condition"sv, m_condition, executable),
LibJS/Bytecode: Make each Jump instruction inherit Instruction directly Before this change, all JumpFoo instructions inherited from Jump, which forced the unconditional Jump to have an unusued "false target" member. Also, labels were unnecessarily wrapped in Optional<>. By defining each jump instruction separately, they all shrink in size, and all ambiguity is removed.
2024-05-05 11:52:14 +02:00
m_true_target,
m_false_target);
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: 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
ByteString JumpTrue::to_byte_string_impl(Bytecode::Executable const& executable) const
{
return ByteString::formatted("JumpTrue {}, {}",
format_operand("condition"sv, m_condition, executable),
m_target);
}
ByteString JumpFalse::to_byte_string_impl(Bytecode::Executable const& executable) const
{
return ByteString::formatted("JumpFalse {}, {}",
format_operand("condition"sv, m_condition, executable),
m_target);
}
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
ByteString JumpNullish::to_byte_string_impl(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
{
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 ByteString::formatted("JumpNullish {}, null:{} nonnull:{}",
format_operand("condition"sv, m_condition, executable),
LibJS/Bytecode: Make each Jump instruction inherit Instruction directly Before this change, all JumpFoo instructions inherited from Jump, which forced the unconditional Jump to have an unusued "false target" member. Also, labels were unnecessarily wrapped in Optional<>. By defining each jump instruction separately, they all shrink in size, and all ambiguity is removed.
2024-05-05 11:52:14 +02:00
m_true_target,
m_false_target);
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 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: 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
ByteString Jump##op_TitleCase::to_byte_string_impl(Bytecode::Executable const& executable) const \
{ \
return ByteString::formatted("Jump" #op_TitleCase " {}, {}, true:{}, false:{}", \
format_operand("lhs"sv, m_lhs, executable), \
format_operand("rhs"sv, m_rhs, executable), \
m_true_target, \
m_false_target); \
}
JS_ENUMERATE_COMPARISON_OPS(HANDLE_COMPARISON_OP)
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
ByteString JumpUndefined::to_byte_string_impl(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
{
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 ByteString::formatted("JumpUndefined {}, undefined:{} defined:{}",
format_operand("condition"sv, m_condition, executable),
LibJS/Bytecode: Make each Jump instruction inherit Instruction directly Before this change, all JumpFoo instructions inherited from Jump, which forced the unconditional Jump to have an unusued "false target" member. Also, labels were unnecessarily wrapped in Optional<>. By defining each jump instruction separately, they all shrink in size, and all ambiguity is removed.
2024-05-05 11:52:14 +02:00
m_true_target,
m_false_target);
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 Call::to_byte_string_impl(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
{
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
StringBuilder builder;
LibJS: Stop passing StringView literals as format strings This was preventing the format string checks from running, which would have caught a bug I was about to introduce.
2025-04-08 16:54:29 +02:00
builder.appendff("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
format_operand("dst"sv, m_dst, executable),
format_operand("callee"sv, m_callee, executable),
format_operand("this"sv, m_this_value, executable));
builder.append(format_operand_list("args"sv, { m_arguments, m_argument_count }, executable));
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
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
if (m_expression_string.has_value()) {
builder.appendff(", `{}`", executable.get_string(m_expression_string.value()));
}
return builder.to_byte_string();
}
ByteString CallConstruct::to_byte_string_impl(Bytecode::Executable const& executable) const
{
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
StringBuilder builder;
LibJS: Stop passing StringView literals as format strings This was preventing the format string checks from running, which would have caught a bug I was about to introduce.
2025-04-08 16:54:29 +02:00
builder.appendff("CallConstruct {}, {}, ",
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
format_operand("dst"sv, m_dst, executable),
LibJS: Remove unused `this` value from CallConstruct instruction There's no `this` value prior in the caller context, and this was never actually used by CallConstruct.
2025-04-06 22:50:55 +02:00
format_operand("callee"sv, m_callee, executable));
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
builder.append(format_operand_list("args"sv, { m_arguments, m_argument_count }, executable));
if (m_expression_string.has_value()) {
builder.appendff(", `{}`", executable.get_string(m_expression_string.value()));
}
return builder.to_byte_string();
}
ByteString CallDirectEval::to_byte_string_impl(Bytecode::Executable const& executable) const
{
StringBuilder builder;
LibJS: Stop passing StringView literals as format strings This was preventing the format string checks from running, which would have caught a bug I was about to introduce.
2025-04-08 16:54:29 +02:00
builder.appendff("CallDirectEval {}, {}, {}, ",
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
format_operand("dst"sv, m_dst, executable),
format_operand("callee"sv, m_callee, executable),
format_operand("this"sv, m_this_value, executable));
builder.append(format_operand_list("args"sv, { m_arguments, m_argument_count }, executable));
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
if (m_expression_string.has_value()) {
builder.appendff(", `{}`", executable.get_string(m_expression_string.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
}
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
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 builder.to_byte_string();
}
ByteString CallBuiltin::to_byte_string_impl(Bytecode::Executable const& executable) const
{
StringBuilder builder;
LibJS: Stop passing StringView literals as format strings This was preventing the format string checks from running, which would have caught a bug I was about to introduce.
2025-04-08 16:54:29 +02:00
builder.appendff("CallBuiltin {}, {}, {}, ",
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
format_operand("dst"sv, m_dst, executable),
format_operand("callee"sv, m_callee, executable),
format_operand("this"sv, m_this_value, executable));
builder.append(format_operand_list("args"sv, { m_arguments, m_argument_count }, executable));
builder.appendff(", (builtin:{})", m_builtin);
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
if (m_expression_string.has_value()) {
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
builder.appendff(", `{}`", executable.get_string(m_expression_string.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
}
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
return builder.to_byte_string();
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 CallWithArgumentArray::to_byte_string_impl(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
{
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
StringBuilder builder;
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
builder.appendff("CallWithArgumentArray {}, {}, {}, {}",
format_operand("dst"sv, m_dst, executable),
format_operand("callee"sv, m_callee, executable),
format_operand("this"sv, m_this_value, executable),
format_operand("arguments"sv, m_arguments, executable));
if (m_expression_string.has_value())
builder.appendff(" ({})", executable.get_string(m_expression_string.value()));
return builder.to_byte_string();
}
ByteString CallDirectEvalWithArgumentArray::to_byte_string_impl(Bytecode::Executable const& executable) const
{
StringBuilder builder;
builder.appendff("CallDirectEvalWithArgumentArray {}, {}, {}, {}",
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
format_operand("dst"sv, m_dst, executable),
format_operand("callee"sv, m_callee, executable),
format_operand("this"sv, m_this_value, executable),
format_operand("arguments"sv, m_arguments, executable));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
if (m_expression_string.has_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
builder.appendff(" ({})", executable.get_string(m_expression_string.value()));
return builder.to_byte_string();
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
ByteString CallConstructWithArgumentArray::to_byte_string_impl(Bytecode::Executable const& executable) const
{
StringBuilder builder;
builder.appendff("CallConstructWithArgumentArray {}, {}, {}",
format_operand("dst"sv, m_dst, executable),
format_operand("callee"sv, m_callee, executable),
format_operand("arguments"sv, m_arguments, executable));
if (m_expression_string.has_value())
builder.appendff(" ({})", executable.get_string(m_expression_string.value()));
return builder.to_byte_string();
}
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
ByteString SuperCallWithArgumentArray::to_byte_string_impl(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
{
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 ByteString::formatted("SuperCallWithArgumentArray {}, {}",
format_operand("dst"sv, m_dst, executable),
format_operand("arguments"sv, m_arguments, executable));
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
ByteString NewFunction::to_byte_string_impl(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
{
StringBuilder builder;
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
builder.appendff("NewFunction {}",
format_operand("dst"sv, m_dst, executable));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
if (m_function_node.has_name())
LibJS: Stop passing StringView literals as format strings This was preventing the format string checks from running, which would have caught a bug I was about to introduce.
2025-04-08 16:54:29 +02:00
builder.appendff(" name:{}", m_function_node.name());
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
if (m_lhs_name.has_value())
LibJS: Stop passing StringView literals as format strings This was preventing the format string checks from running, which would have caught a bug I was about to introduce.
2025-04-08 16:54:29 +02:00
builder.appendff(" lhs_name:{}", executable.get_identifier(m_lhs_name.value()));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
if (m_home_object.has_value())
LibJS: Stop passing StringView literals as format strings This was preventing the format string checks from running, which would have caught a bug I was about to introduce.
2025-04-08 16:54:29 +02:00
builder.appendff(", {}", format_operand("home_object"sv, m_home_object.value(), executable));
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 builder.to_byte_string();
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
ByteString NewClass::to_byte_string_impl(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
{
StringBuilder builder;
auto name = m_class_expression.name();
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
builder.appendff("NewClass {}",
format_operand("dst"sv, m_dst, executable));
if (m_super_class.has_value())
builder.appendff(", {}", format_operand("super_class"sv, *m_super_class, executable));
if (!name.is_empty())
builder.appendff(", {}", name);
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
if (m_lhs_name.has_value())
LibJS: Stop passing StringView literals as format strings This was preventing the format string checks from running, which would have caught a bug I was about to introduce.
2025-04-08 16:54:29 +02:00
builder.appendff(", lhs_name:{}", executable.get_identifier(m_lhs_name.value()));
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 builder.to_byte_string();
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
ByteString Return::to_byte_string_impl(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
{
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
return ByteString::formatted("Return {}", format_operand("value"sv, m_value, executable));
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
ByteString Increment::to_byte_string_impl(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
{
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 ByteString::formatted("Increment {}", format_operand("dst"sv, m_dst, executable));
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: 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
ByteString PostfixIncrement::to_byte_string_impl(Bytecode::Executable const& executable) const
{
return ByteString::formatted("PostfixIncrement {}, {}",
format_operand("dst"sv, m_dst, executable),
LibJS/Bytecode: Fix bad serialization of Postfix{Increment,Decrement} We were serializing the dst operand twice in both instructions.
2024-03-03 09:04:30 +01:00
format_operand("src"sv, m_src, executable));
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
}
ByteString Decrement::to_byte_string_impl(Bytecode::Executable const& executable) const
{
return ByteString::formatted("Decrement {}", format_operand("dst"sv, m_dst, executable));
}
ByteString PostfixDecrement::to_byte_string_impl(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
{
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 ByteString::formatted("PostfixDecrement {}, {}",
format_operand("dst"sv, m_dst, executable),
LibJS/Bytecode: Fix bad serialization of Postfix{Increment,Decrement} We were serializing the dst operand twice in both instructions.
2024-03-03 09:04:30 +01:00
format_operand("src"sv, m_src, executable));
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
ByteString Throw::to_byte_string_impl(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
{
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 ByteString::formatted("Throw {}",
format_operand("src"sv, m_src, executable));
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
ByteString ThrowIfNotObject::to_byte_string_impl(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
{
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 ByteString::formatted("ThrowIfNotObject {}",
format_operand("src"sv, m_src, executable));
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
ByteString ThrowIfNullish::to_byte_string_impl(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
{
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 ByteString::formatted("ThrowIfNullish {}",
format_operand("src"sv, m_src, executable));
}
ByteString ThrowIfTDZ::to_byte_string_impl(Bytecode::Executable const& executable) const
{
return ByteString::formatted("ThrowIfTDZ {}",
format_operand("src"sv, m_src, executable));
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 EnterUnwindContext::to_byte_string_impl(Bytecode::Executable const&) const
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
return ByteString::formatted("EnterUnwindContext entry:{}", m_entry_point);
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 ScheduleJump::to_byte_string_impl(Bytecode::Executable const&) const
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
return ByteString::formatted("ScheduleJump {}", m_target);
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 LeaveLexicalEnvironment::to_byte_string_impl(Bytecode::Executable const&) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
return "LeaveLexicalEnvironment"sv;
}
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
ByteString LeavePrivateEnvironment::to_byte_string_impl(Bytecode::Executable const&) const
{
return "LeavePrivateEnvironment"sv;
}
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 LeaveUnwindContext::to_byte_string_impl(Bytecode::Executable const&) const
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
{
return "LeaveUnwindContext";
}
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 ContinuePendingUnwind::to_byte_string_impl(Bytecode::Executable const&) const
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
return ByteString::formatted("ContinuePendingUnwind resume:{}", m_resume_target);
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
ByteString Yield::to_byte_string_impl(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
{
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
if (m_continuation_label.has_value()) {
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 ByteString::formatted("Yield continuation:{}, {}",
m_continuation_label.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
format_operand("value"sv, m_value, executable));
}
return ByteString::formatted("Yield return {}",
format_operand("value"sv, m_value, executable));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
LibJS: Prepare yield object before re-routing it through finally
2024-05-18 17:25:43 +02:00
ByteString PrepareYield::to_byte_string_impl(Bytecode::Executable const& executable) const
{
return ByteString::formatted("PrepareYield {}, {}",
format_operand("dst"sv, m_dest, executable),
format_operand("value"sv, m_value, executable));
}
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
ByteString Await::to_byte_string_impl(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
{
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 ByteString::formatted("Await {}, continuation:{}",
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
format_operand("argument"sv, m_argument, executable),
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
m_continuation_label);
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
ByteString GetByValue::to_byte_string_impl(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
{
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 ByteString::formatted("GetByValue {}, {}, {}",
format_operand("dst"sv, m_dst, executable),
format_operand("base"sv, m_base, executable),
format_operand("property"sv, m_property, executable));
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
ByteString GetByValueWithThis::to_byte_string_impl(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
{
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 ByteString::formatted("GetByValueWithThis {}, {}, {}",
format_operand("dst"sv, m_dst, executable),
format_operand("base"sv, m_base, executable),
format_operand("property"sv, m_property, executable));
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
ByteString PutByValue::to_byte_string_impl(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
{
auto kind = property_kind_to_string(m_kind);
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 ByteString::formatted("PutByValue {}, {}, {}, kind:{}",
format_operand("base"sv, m_base, executable),
format_operand("property"sv, m_property, executable),
format_operand("src"sv, m_src, executable),
kind);
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
ByteString PutByValueWithThis::to_byte_string_impl(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
{
auto kind = property_kind_to_string(m_kind);
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 ByteString::formatted("PutByValueWithThis {}, {}, {}, {}, kind:{}",
format_operand("base"sv, m_base, executable),
format_operand("property"sv, m_property, executable),
format_operand("src"sv, m_src, executable),
format_operand("this"sv, m_this_value, executable),
kind);
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
ByteString DeleteByValue::to_byte_string_impl(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
{
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 ByteString::formatted("DeleteByValue {}, {}, {}",
format_operand("dst"sv, dst(), executable),
format_operand("base"sv, m_base, executable),
format_operand("property"sv, m_property, executable));
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
ByteString DeleteByValueWithThis::to_byte_string_impl(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
{
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 ByteString::formatted("DeleteByValueWithThis {}, {}, {}, {}",
format_operand("dst"sv, dst(), executable),
format_operand("base"sv, m_base, executable),
format_operand("property"sv, m_property, executable),
format_operand("this"sv, m_this_value, executable));
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
ByteString GetIterator::to_byte_string_impl(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
{
auto hint = m_hint == IteratorHint::Sync ? "sync" : "async";
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 ByteString::formatted("GetIterator {}, {}, hint:{}",
format_operand("dst"sv, m_dst, executable),
format_operand("iterable"sv, m_iterable, executable),
hint);
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 GetMethod::to_byte_string_impl(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
{
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 ByteString::formatted("GetMethod {}, {}, {}",
format_operand("dst"sv, m_dst, executable),
format_operand("object"sv, m_object, executable),
executable.identifier_table->get(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
}
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
ByteString GetObjectPropertyIterator::to_byte_string_impl(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
{
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 ByteString::formatted("GetObjectPropertyIterator {}, {}",
format_operand("dst"sv, dst(), executable),
format_operand("object"sv, object(), executable));
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
ByteString IteratorClose::to_byte_string_impl(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
{
if (!m_completion_value.has_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 ByteString::formatted("IteratorClose {}, completion_type={} completion_value=<empty>",
format_operand("iterator_record"sv, m_iterator_record, executable),
to_underlying(m_completion_type));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
auto completion_value_string = m_completion_value->to_string_without_side_effects();
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 ByteString::formatted("IteratorClose {}, completion_type={} completion_value={}",
format_operand("iterator_record"sv, m_iterator_record, executable),
to_underlying(m_completion_type), completion_value_string);
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
ByteString AsyncIteratorClose::to_byte_string_impl(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
{
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
if (!m_completion_value.has_value()) {
return ByteString::formatted("AsyncIteratorClose {}, completion_type:{} completion_value:<empty>",
format_operand("iterator_record"sv, m_iterator_record, executable),
to_underlying(m_completion_type));
}
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
return ByteString::formatted("AsyncIteratorClose {}, completion_type:{}, completion_value:{}",
format_operand("iterator_record"sv, m_iterator_record, executable),
to_underlying(m_completion_type), 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
}
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
ByteString IteratorNext::to_byte_string_impl(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
{
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 ByteString::formatted("IteratorNext {}, {}",
format_operand("dst"sv, m_dst, executable),
format_operand("iterator_record"sv, m_iterator_record, executable));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
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
ByteString IteratorNextUnpack::to_byte_string_impl(Executable const& executable) 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
{
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
return ByteString::formatted("IteratorNextUnpack {}, {}, {}",
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
format_operand("dst_value"sv, m_dst_value, executable),
format_operand("dst_done"sv, m_dst_done, executable),
format_operand("iterator_record"sv, m_iterator_record, executable));
}
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
ByteString ResolveThisBinding::to_byte_string_impl(Bytecode::Executable const&) 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: 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 "ResolveThisBinding"sv;
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
ByteString ResolveSuperBase::to_byte_string_impl(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
{
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 ByteString::formatted("ResolveSuperBase {}",
format_operand("dst"sv, m_dst, executable));
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
ByteString GetNewTarget::to_byte_string_impl(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
{
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 ByteString::formatted("GetNewTarget {}", format_operand("dst"sv, m_dst, executable));
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
ByteString GetImportMeta::to_byte_string_impl(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
{
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 ByteString::formatted("GetImportMeta {}", format_operand("dst"sv, m_dst, executable));
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: Rename TypeofVariable => TypeofBinding
2024-06-14 09:37:26 +02:00
ByteString TypeofBinding::to_byte_string_impl(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
{
LibJS/Bytecode: Rename TypeofVariable => TypeofBinding
2024-06-14 09:37:26 +02:00
return ByteString::formatted("TypeofBinding {}, {}",
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
format_operand("dst"sv, m_dst, executable),
executable.identifier_table->get(m_identifier));
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
ByteString BlockDeclarationInstantiation::to_byte_string_impl(Bytecode::Executable const&) 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
return "BlockDeclarationInstantiation"sv;
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
ByteString ImportCall::to_byte_string_impl(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
{
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 ByteString::formatted("ImportCall {}, {}, {}",
format_operand("dst"sv, m_dst, executable),
format_operand("specifier"sv, m_specifier, executable),
format_operand("options"sv, m_options, executable));
}
ByteString Catch::to_byte_string_impl(Bytecode::Executable const& executable) const
{
return ByteString::formatted("Catch {}",
format_operand("dst"sv, m_dst, executable));
LibJS: Move all bytecode instruction implementations to Interpreter.cpp This allows aggressive inlining without LTO.
2023-09-27 10:10:00 +02:00
}
LibJS: Cleanup unwind state when transferring control out of a finalizer This does two things: * Clear exceptions when transferring control out of a finalizer Otherwise they would resurface at the end of the next finalizer (see test the new test case), or at the end of a function * Pop one scheduled jump when transferring control out of a finalizer This removes one old FIXME
2024-04-11 11:58:18 +02:00
ByteString LeaveFinally::to_byte_string_impl(Bytecode::Executable const&) const
{
return ByteString::formatted("LeaveFinally");
}
LibJS: Restore scheduled jumps in catch blocks without finalizers
2024-04-11 11:07:35 +02:00
ByteString RestoreScheduledJump::to_byte_string_impl(Bytecode::Executable const&) const
{
return ByteString::formatted("RestoreScheduledJump");
}
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
ByteString GetObjectFromIteratorRecord::to_byte_string_impl(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
{
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 ByteString::formatted("GetObjectFromIteratorRecord {}, {}",
format_operand("object"sv, m_object, executable),
format_operand("iterator_record"sv, m_iterator_record, executable));
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
ByteString GetNextMethodFromIteratorRecord::to_byte_string_impl(Bytecode::Executable const& executable) 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
{
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 ByteString::formatted("GetNextMethodFromIteratorRecord {}, {}",
format_operand("next_method"sv, m_next_method, executable),
format_operand("iterator_record"sv, m_iterator_record, executable));
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
}
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
ByteString End::to_byte_string_impl(Bytecode::Executable const& executable) const
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
{
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 ByteString::formatted("End {}", format_operand("value"sv, m_value, executable));
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
}
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
ByteString Dump::to_byte_string_impl(Bytecode::Executable const& executable) const
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
{
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 ByteString::formatted("Dump '{}', {}", m_text,
format_operand("value"sv, m_value, executable));
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
}
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
}
ByteString GetCompletionFields::to_byte_string_impl(Bytecode::Executable const& executable) const
{
return ByteString::formatted("GetCompletionFields {}, {}, {}",
format_operand("value_dst"sv, m_value_dst, executable),
format_operand("type_dst"sv, m_type_dst, executable),
format_operand("completion"sv, m_completion, executable));
}
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: Make SetCompletionType bytecode instruction actually set type This recovers 38 tests in test262 that regressed in a0bb31f7a0e.
2025-04-05 14:06:33 +02:00
completion_cell.set_completion(Completion { m_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
}
ByteString SetCompletionType::to_byte_string_impl(Bytecode::Executable const& executable) const
{
return ByteString::formatted("SetCompletionType {}, type={}",
format_operand("completion"sv, m_completion, executable),
to_underlying(m_type));
}
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