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

1885 lines
82 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: Generate bytecode for the BlockDeclarationInstantiation AO This necessitated adding some new instructions for creating mutable and immutable bindings.
2025-10-25 14:06:48 +02:00
* Copyright (c) 2021-2025, Andreas Kling <andreas@ladybird.org>
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: Skip initializing constant slots in ExecutionContext Every function call allocates an ExecutionContext with a trailing array of Values for registers, locals, constants, and arguments. Previously, the constructor would initialize all slots to js_special_empty_value(), but constant slots were then immediately overwritten by the interpreter copying in values from the Executable before execution began. To eliminate this redundant initialization, we rearrange the layout from [registers | constants | locals] to [registers | locals | constants]. This groups registers and locals together at the front, allowing us to initialize only those slots while leaving constant slots uninitialized until they're populated with their actual values. This reduces the per-call initialization cost from O(registers + locals + constants) to O(registers + locals). Also tightens up the types involved (size_t -> u32) and adds VERIFYs to guard against overflow when computing the combined slot counts, and to ensure the total fits within the 29-bit operand index field.
2026-01-18 23:17:10 +01:00
#include <AK/Checked.h>
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
#include <AK/QuickSort.h>
LibJS: Create static unwind mappings for `BasicBlock`s This is currently only used in the bytecode dump to annotate to where unwinds lead per block, but will be hooked up to the virtual machine in the next commit.
2023-10-19 23:18:54 +02:00
#include <AK/TemporaryChange.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/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>
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/Generator.h>
#include <LibJS/Bytecode/Instruction.h>
LibJS: Automatically split linear bytecode into multiple blocks ...instead of crashing :^)
2021-06-11 01:35:01 +04:30
#include <LibJS/Bytecode/Op.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/Register.h>
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
#include <LibJS/Runtime/ECMAScriptFunctionObject.h>
LibJS: Introduce NativeJavaScriptBackedFunction This hosts the ability to compile and run JavaScript to implement native functions. This is particularly useful for any native function that is not a normal function, for example async functions such as Array.fromAsync, which require yielding. These functions are not allowed to observe anything from outside their environment. Any global identifiers will instead be assumed to be a reference to an abstract operation or a constant. The generator will inject the appropriate bytecode if the name of the global identifier matches a known name. Anything else will cause a code generation error.
2025-11-06 19:00:36 +00:00
#include <LibJS/Runtime/NativeJavaScriptBackedFunction.h>
LibJS: Pre-create SharedFunctionInstanceData in NewFunction Replace the FunctionNode const& stored on the NewFunction bytecode instruction with an index into a table of pre-created SharedFunctionInstanceData objects on the Executable. During bytecode compilation, we now eagerly create SharedFunctionInstanceData for each function that will be instantiated by NewFunction, and store it on both the FunctionNode (for caching) and the Executable (for GC tracing). At runtime, NewFunction simply looks up the SharedFunctionInstanceData by index and calls create_from_function_data() directly, bypassing the AST entirely. This removes one of the main reasons the AST had to stay alive after compilation. The instantiate_ordinary_function_expression() helper in Interpreter.cpp is removed as its non-trivial code path (creating a scope for named function expressions) was dead code -- it was only called when !has_name(), so the has_own_name branch never executed.
2026-02-10 23:02:46 +01:00
#include <LibJS/Runtime/SharedFunctionInstanceData.h>
LibJS: Make Bytecode::Executable GC-allocated This is a step towards making ExecutionContext easier to allocate.
2023-11-27 13:23:59 +01:00
#include <LibJS/Runtime/VM.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: Introduce NativeJavaScriptBackedFunction This hosts the ability to compile and run JavaScript to implement native functions. This is particularly useful for any native function that is not a normal function, for example async functions such as Array.fromAsync, which require yielding. These functions are not allowed to observe anything from outside their environment. Any global identifiers will instead be assumed to be a reference to an abstract operation or a constant. The generator will inject the appropriate bytecode if the name of the global identifier matches a known name. Anything else will cause a code generation error.
2025-11-06 19:00:36 +00:00
Generator::Generator(VM& vm, GC::Ptr<SharedFunctionInstanceData const> shared_function_instance_data, MustPropagateCompletion must_propagate_completion, BuiltinAbstractOperationsEnabled builtin_abstract_operations_enabled)
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
: m_vm(vm)
, m_string_table(make<StringTable>())
LibJS: Add a separate "identifier table" to bytecode executables This is a specialized string table for storing identifiers only. Identifiers are always FlyStrings, which makes many common operations faster by allowing O(1) comparison.
2021-10-24 15:34:30 +02:00
, m_identifier_table(make<IdentifierTable>())
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
, m_property_key_table(make<PropertyKeyTable>())
LibJS/Bytecode: Don't reparse regular expressions on instantiation The RegExpLiteral AST node already has the parsed regex::Parser::Result so let's plumb that over to the bytecode executable instead of reparsing the regex every time NewRegExp is executed. ~12% speed-up on language/literals/regexp/S7.8.5_A2.1_T2.js in test262.
2023-07-13 10:49:07 +02:00
, m_regex_table(make<RegexTable>())
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
, m_constants(vm.heap())
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
, m_accumulator(*this, Operand(Register::accumulator()))
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
, m_this_value(*this, Operand(Register::this_value()))
LibJS/Bytecode: Don't bother propagating completion values in functions The last completion value in a function is not exposed to the language, since functions always either return something, or undefined. Given this, we can avoid emitting code that propagates the completion value from various statements, as long as we know we're generating code for a context where the completion value is not accessible. In practical terms, this means that function code gets to do less completion shuffling, while global and eval code has to keep doing it.
2024-05-14 10:57:06 +02:00
, m_must_propagate_completion(must_propagate_completion == MustPropagateCompletion::Yes)
LibJS: Introduce NativeJavaScriptBackedFunction This hosts the ability to compile and run JavaScript to implement native functions. This is particularly useful for any native function that is not a normal function, for example async functions such as Array.fromAsync, which require yielding. These functions are not allowed to observe anything from outside their environment. Any global identifiers will instead be assumed to be a reference to an abstract operation or a constant. The generator will inject the appropriate bytecode if the name of the global identifier matches a known name. Anything else will cause a code generation error.
2025-11-06 19:00:36 +00:00
, m_builtin_abstract_operations_enabled(builtin_abstract_operations_enabled == BuiltinAbstractOperationsEnabled::Yes)
LibJS/Bytecode: Make compilation use SharedFunctionInstanceData instead All the data we need for compilation is in SharedFunctionInstanceData, so we shouldn't depend on ECMAScriptFunctionObject. Allows NativeJavaScriptBackedFunction to compile bytecode.
2025-11-06 17:26:02 +00:00
, m_shared_function_instance_data(shared_function_instance_data)
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: Pre-create SharedFunctionInstanceData in NewFunction Replace the FunctionNode const& stored on the NewFunction bytecode instruction with an index into a table of pre-created SharedFunctionInstanceData objects on the Executable. During bytecode compilation, we now eagerly create SharedFunctionInstanceData for each function that will be instantiated by NewFunction, and store it on both the FunctionNode (for caching) and the Executable (for GC tracing). At runtime, NewFunction simply looks up the SharedFunctionInstanceData by index and calls create_from_function_data() directly, bypassing the AST entirely. This removes one of the main reasons the AST had to stay alive after compilation. The instantiate_ordinary_function_expression() helper in Interpreter.cpp is removed as its non-trivial code path (creating a scope for named function expressions) was dead code -- it was only called when !has_name(), so the has_own_name branch never executed.
2026-02-10 23:02:46 +01:00
static GC::Ref<SharedFunctionInstanceData> ensure_shared_function_data(VM& vm, FunctionNode const& function_node, Utf16FlyString name)
{
LibJS: Move SharedFunctionInstanceData creation out of FunctionNode Add static factory methods create_for_function_node() on SharedFunctionInstanceData and update all callers to use them instead of FunctionNode::ensure_shared_data(). This removes the GC::Root<SharedFunctionInstanceData> cache from FunctionNode, eliminating the coupling between the RefCounted AST and GC-managed runtime objects. The cache was effectively dead code: hoisted declarations use m_functions_to_initialize directly, and function expressions always create fresh instances during codegen.
2026-02-11 11:51:48 +01:00
return SharedFunctionInstanceData::create_for_function_node(vm, function_node, move(name));
LibJS: Pre-create SharedFunctionInstanceData in NewFunction Replace the FunctionNode const& stored on the NewFunction bytecode instruction with an index into a table of pre-created SharedFunctionInstanceData objects on the Executable. During bytecode compilation, we now eagerly create SharedFunctionInstanceData for each function that will be instantiated by NewFunction, and store it on both the FunctionNode (for caching) and the Executable (for GC tracing). At runtime, NewFunction simply looks up the SharedFunctionInstanceData by index and calls create_from_function_data() directly, bypassing the AST entirely. This removes one of the main reasons the AST had to stay alive after compilation. The instantiate_ordinary_function_expression() helper in Interpreter.cpp is removed as its non-trivial code path (creating a scope for named function expressions) was dead code -- it was only called when !has_name(), so the has_own_name branch never executed.
2026-02-10 23:02:46 +01:00
}
u32 Generator::register_shared_function_data(GC::Ref<SharedFunctionInstanceData> data)
{
auto index = static_cast<u32>(m_shared_function_data.size());
m_shared_function_data.append(data);
return index;
}
LibJS: Populate ClassBlueprint during codegen Build a ClassBlueprint from ClassExpression elements at codegen time: - Methods/getters/setters: register SharedFunctionInstanceData from the method's FunctionExpression - Field initializers with literal values (numbers, booleans, null, strings, negated numbers): store the value directly, avoiding function creation entirely - Field initializers with non-literal values: wrap in ClassFieldInitializerStatement and create SharedFunctionInstanceData - Static initializers: create SharedFunctionInstanceData from the function body - Constructor: register SharedFunctionInstanceData from the constructor's FunctionExpression Add public accessors to ClassMethod::function() and StaticInitializer::function_body() for codegen access. The blueprint is registered but not yet used by NewClass (dual path). No behavioral change.
2026-02-11 00:20:47 +01:00
u32 Generator::register_class_blueprint(ClassBlueprint blueprint)
{
auto index = static_cast<u32>(m_class_blueprints.size());
m_class_blueprints.append(move(blueprint));
return index;
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
void Generator::emit_function_declaration_instantiation(SharedFunctionInstanceData const& shared_function_instance_data)
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: Make compilation use SharedFunctionInstanceData instead All the data we need for compilation is in SharedFunctionInstanceData, so we shouldn't depend on ECMAScriptFunctionObject. Allows NativeJavaScriptBackedFunction to compile bytecode.
2025-11-06 17:26:02 +00:00
if (shared_function_instance_data.m_has_parameter_expressions) {
LibJS: Elide empty lexical environments for parameter evaluation If all the parameter default values end up in locals, the lexical environment we create to hold them would never be used for anything, and so we can elide it and avoid the GC work.
2025-03-20 08:51:45 -05:00
bool has_non_local_parameters = false;
LibJS/Bytecode: Make compilation use SharedFunctionInstanceData instead All the data we need for compilation is in SharedFunctionInstanceData, so we shouldn't depend on ECMAScriptFunctionObject. Allows NativeJavaScriptBackedFunction to compile bytecode.
2025-11-06 17:26:02 +00:00
for (auto const& parameter_name : shared_function_instance_data.m_parameter_names) {
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
if (parameter_name.value == SharedFunctionInstanceData::ParameterIsLocal::No) {
LibJS: Elide empty lexical environments for parameter evaluation If all the parameter default values end up in locals, the lexical environment we create to hold them would never be used for anything, and so we can elide it and avoid the GC work.
2025-03-20 08:51:45 -05:00
has_non_local_parameters = true;
break;
}
}
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
if (has_non_local_parameters) {
auto parent_environment = m_lexical_environment_register_stack.last();
auto new_environment = allocate_register();
emit<Op::CreateLexicalEnvironment>(new_environment, parent_environment, 0);
m_lexical_environment_register_stack.append(new_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: Make compilation use SharedFunctionInstanceData instead All the data we need for compilation is in SharedFunctionInstanceData, so we shouldn't depend on ECMAScriptFunctionObject. Allows NativeJavaScriptBackedFunction to compile bytecode.
2025-11-06 17:26:02 +00:00
for (auto const& parameter_name : shared_function_instance_data.m_parameter_names) {
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
if (parameter_name.value == SharedFunctionInstanceData::ParameterIsLocal::No) {
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 id = intern_identifier(parameter_name.key);
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
emit<Op::CreateVariable>(id, Op::EnvironmentMode::Lexical, false, false, false);
LibJS/Bytecode: Make compilation use SharedFunctionInstanceData instead All the data we need for compilation is in SharedFunctionInstanceData, so we shouldn't depend on ECMAScriptFunctionObject. Allows NativeJavaScriptBackedFunction to compile bytecode.
2025-11-06 17:26:02 +00:00
if (shared_function_instance_data.m_has_duplicates) {
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
emit<Op::InitializeLexicalBinding>(id, add_constant(js_undefined()));
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
}
}
}
LibJS/Bytecode: Make compilation use SharedFunctionInstanceData instead All the data we need for compilation is in SharedFunctionInstanceData, so we shouldn't depend on ECMAScriptFunctionObject. Allows NativeJavaScriptBackedFunction to compile bytecode.
2025-11-06 17:26:02 +00:00
if (shared_function_instance_data.m_arguments_object_needed) {
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
Optional<Operand> dst;
LibJS/Bytecode: Make compilation use SharedFunctionInstanceData instead All the data we need for compilation is in SharedFunctionInstanceData, so we shouldn't depend on ECMAScriptFunctionObject. Allows NativeJavaScriptBackedFunction to compile bytecode.
2025-11-06 17:26:02 +00:00
auto local_var_index = shared_function_instance_data.m_local_variables_names.find_first_index_if([](auto const& local) { return local.declaration_kind == LocalVariable::DeclarationKind::ArgumentsObject; });
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 (local_var_index.has_value())
LibJS: Skip allocating locals for arguments that allowed to be local This allows us to get rid of instructions that move arguments to locals and allocate smaller JS::Value vector in ExecutionContext by reusing slots that were already allocated for arguments. With this change for following function: ```js function f(x, y) { return x + y; } ``` we now produce following bytecode: ``` [ 0] 0: Add dst:reg6, lhs:arg0, rhs:arg1 [ 10] Return value:reg6 ``` instead of: ``` [ 0] 0: GetArgument 0, dst:x~1 [ 10] GetArgument 1, dst:y~0 [ 20] Add dst:reg6, lhs:x~1, rhs:y~0 [ 30] Return value:reg6 ```
2025-04-25 17:10:47 +02:00
dst = local(Identifier::Local::variable(local_var_index.value()));
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/Bytecode: Make compilation use SharedFunctionInstanceData instead All the data we need for compilation is in SharedFunctionInstanceData, so we shouldn't depend on ECMAScriptFunctionObject. Allows NativeJavaScriptBackedFunction to compile bytecode.
2025-11-06 17:26:02 +00:00
if (shared_function_instance_data.m_strict || !shared_function_instance_data.m_has_simple_parameter_list) {
emit<Op::CreateArguments>(dst, Op::ArgumentsKind::Unmapped, shared_function_instance_data.m_strict);
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
} else {
LibJS/Bytecode: Make compilation use SharedFunctionInstanceData instead All the data we need for compilation is in SharedFunctionInstanceData, so we shouldn't depend on ECMAScriptFunctionObject. Allows NativeJavaScriptBackedFunction to compile bytecode.
2025-11-06 17:26:02 +00:00
emit<Op::CreateArguments>(dst, Op::ArgumentsKind::Mapped, shared_function_instance_data.m_strict);
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: Mark `arguments` local as initialized after creating it This avoids emitting an unnecessary TDZ check for the first time we access the arguments object.
2025-04-26 11:57:34 +02:00
if (local_var_index.has_value())
set_local_initialized(Identifier::Local::variable(local_var_index.value()));
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
}
LibJS/Bytecode: Make compilation use SharedFunctionInstanceData instead All the data we need for compilation is in SharedFunctionInstanceData, so we shouldn't depend on ECMAScriptFunctionObject. Allows NativeJavaScriptBackedFunction to compile bytecode.
2025-11-06 17:26:02 +00:00
auto const& formal_parameters = *shared_function_instance_data.m_formal_parameters;
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
for (u32 param_index = 0; param_index < formal_parameters.size(); ++param_index) {
auto const& parameter = formal_parameters.parameters()[param_index];
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 (parameter.is_rest) {
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
emit<Op::CreateRestParams>(Operand { Operand::Type::Argument, param_index }, param_index);
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
} else if (parameter.default_value) {
auto& if_undefined_block = make_block();
auto& if_not_undefined_block = make_block();
emit<Op::JumpUndefined>(
LibJS: Skip allocating locals for arguments that allowed to be local This allows us to get rid of instructions that move arguments to locals and allocate smaller JS::Value vector in ExecutionContext by reusing slots that were already allocated for arguments. With this change for following function: ```js function f(x, y) { return x + y; } ``` we now produce following bytecode: ``` [ 0] 0: Add dst:reg6, lhs:arg0, rhs:arg1 [ 10] Return value:reg6 ``` instead of: ``` [ 0] 0: GetArgument 0, dst:x~1 [ 10] GetArgument 1, dst:y~0 [ 20] Add dst:reg6, lhs:x~1, rhs:y~0 [ 30] Return value:reg6 ```
2025-04-25 17:10:47 +02:00
Operand { Operand::Type::Argument, param_index },
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
Label { if_undefined_block },
Label { if_not_undefined_block });
switch_to_basic_block(if_undefined_block);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto operand = parameter.default_value->generate_bytecode(*this);
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
emit<Op::Mov>(Operand { Operand::Type::Argument, param_index }, *operand);
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
emit<Op::Jump>(Label { if_not_undefined_block });
switch_to_basic_block(if_not_undefined_block);
}
if (auto const* identifier = parameter.binding.get_pointer<NonnullRefPtr<Identifier const>>(); identifier) {
if ((*identifier)->is_local()) {
LibJS: Skip allocating locals for arguments that allowed to be local This allows us to get rid of instructions that move arguments to locals and allocate smaller JS::Value vector in ExecutionContext by reusing slots that were already allocated for arguments. With this change for following function: ```js function f(x, y) { return x + y; } ``` we now produce following bytecode: ``` [ 0] 0: Add dst:reg6, lhs:arg0, rhs:arg1 [ 10] Return value:reg6 ``` instead of: ``` [ 0] 0: GetArgument 0, dst:x~1 [ 10] GetArgument 1, dst:y~0 [ 20] Add dst:reg6, lhs:x~1, rhs:y~0 [ 30] Return value:reg6 ```
2025-04-25 17:10:47 +02:00
set_local_initialized((*identifier)->local_index());
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
} else {
auto id = intern_identifier((*identifier)->string());
LibJS/Bytecode: Make compilation use SharedFunctionInstanceData instead All the data we need for compilation is in SharedFunctionInstanceData, so we shouldn't depend on ECMAScriptFunctionObject. Allows NativeJavaScriptBackedFunction to compile bytecode.
2025-11-06 17:26:02 +00:00
if (shared_function_instance_data.m_has_duplicates) {
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
emit<Op::SetLexicalBinding>(id, Operand { Operand::Type::Argument, param_index });
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
} else {
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
emit<Op::InitializeLexicalBinding>(id, Operand { Operand::Type::Argument, param_index });
LibJS/Bytecode: Split SetVariable into four separate instructions Instead of SetVariable having 2x2 modes for variable/lexical and initialize/set, those 4 modes are now separate instructions, which makes each instruction much less branchy.
2024-05-14 11:30:30 +02:00
}
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
}
} else if (auto const* binding_pattern = parameter.binding.get_pointer<NonnullRefPtr<BindingPattern const>>(); binding_pattern) {
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
ScopedOperand argument { *this, Operand { Operand::Type::Argument, param_index } };
LibJS/Bytecode: Make compilation use SharedFunctionInstanceData instead All the data we need for compilation is in SharedFunctionInstanceData, so we shouldn't depend on ECMAScriptFunctionObject. Allows NativeJavaScriptBackedFunction to compile bytecode.
2025-11-06 17:26:02 +00:00
auto init_mode = shared_function_instance_data.m_has_duplicates ? Op::BindingInitializationMode::Set : Bytecode::Op::BindingInitializationMode::Initialize;
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
(*binding_pattern)->generate_bytecode(*this, init_mode, argument);
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
}
}
LibJS/Bytecode: Make compilation use SharedFunctionInstanceData instead All the data we need for compilation is in SharedFunctionInstanceData, so we shouldn't depend on ECMAScriptFunctionObject. Allows NativeJavaScriptBackedFunction to compile bytecode.
2025-11-06 17:26:02 +00:00
if (!shared_function_instance_data.m_has_parameter_expressions) {
LibJS: Pre-compute ScopeNode queries in SharedFunctionInstanceData Pre-compute the data that emit_function_declaration_instantiation previously obtained by querying ScopeNode methods at codegen time: - m_has_scope_body: whether ecmascript_code is a ScopeNode - m_has_non_local_lexical_declarations: from ScopeNode query - m_lexical_bindings: non-local lexically-scoped identifier names and their constant-declaration status After this change, emit_function_declaration_instantiation no longer casts m_ecmascript_code to ScopeNode or calls any ScopeNode methods.
2026-02-11 01:10:40 +01:00
if (shared_function_instance_data.m_has_scope_body) {
LibJS: Replace VariableNameToInitialize with value-type VarBinding Replace VariableNameToInitialize (which holds Identifier const&) with a VarBinding struct that stores pre-extracted values: name, local index, parameter_binding, and function_name. This removes a reference to AST Identifier nodes from SharedFunctionInstanceData, allowing the AST to be freed after compilation.
2026-02-11 01:06:58 +01:00
for (auto const& var : shared_function_instance_data.m_var_names_to_initialize_binding) {
if (var.local.is_variable() || var.local.is_argument()) {
emit<Op::Mov>(local(var.local), add_constant(js_undefined()));
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
} else {
LibJS: Replace VariableNameToInitialize with value-type VarBinding Replace VariableNameToInitialize (which holds Identifier const&) with a VarBinding struct that stores pre-extracted values: name, local index, parameter_binding, and function_name. This removes a reference to AST Identifier nodes from SharedFunctionInstanceData, allowing the AST to be freed after compilation.
2026-02-11 01:06:58 +01:00
auto intern_id = intern_identifier(var.name);
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
emit<Op::CreateVariable>(intern_id, Op::EnvironmentMode::Var, false, false, false);
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
emit<Op::InitializeVariableBinding>(intern_id, add_constant(js_undefined()));
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
}
}
}
} else {
LibJS: Replace VariableNameToInitialize with value-type VarBinding Replace VariableNameToInitialize (which holds Identifier const&) with a VarBinding struct that stores pre-extracted values: name, local index, parameter_binding, and function_name. This removes a reference to AST Identifier nodes from SharedFunctionInstanceData, allowing the AST to be freed after compilation.
2026-02-11 01:06:58 +01:00
bool has_non_local_vars = false;
LibJS: Pre-compute ScopeNode queries in SharedFunctionInstanceData Pre-compute the data that emit_function_declaration_instantiation previously obtained by querying ScopeNode methods at codegen time: - m_has_scope_body: whether ecmascript_code is a ScopeNode - m_has_non_local_lexical_declarations: from ScopeNode query - m_lexical_bindings: non-local lexically-scoped identifier names and their constant-declaration status After this change, emit_function_declaration_instantiation no longer casts m_ecmascript_code to ScopeNode or calls any ScopeNode methods.
2026-02-11 01:10:40 +01:00
if (shared_function_instance_data.m_has_scope_body) {
LibJS: Replace VariableNameToInitialize with value-type VarBinding Replace VariableNameToInitialize (which holds Identifier const&) with a VarBinding struct that stores pre-extracted values: name, local index, parameter_binding, and function_name. This removes a reference to AST Identifier nodes from SharedFunctionInstanceData, allowing the AST to be freed after compilation.
2026-02-11 01:06:58 +01:00
for (auto const& var : shared_function_instance_data.m_var_names_to_initialize_binding) {
if (!var.local.is_variable() && !var.local.is_argument()) {
has_non_local_vars = true;
LibJS: Elide empty variable environment for default parameters No need to create a separate variable environment if all the parameters are going into locals anyway.
2025-03-20 17:37:48 -05:00
break;
}
}
}
LibJS: Fix scoping of function declarations with destructured params When a function has parameter expressions (e.g. destructured params with defaults), CreateVariableEnvironment creates a separate variable environment for function declarations and sets it as the current lexical environment at runtime. However, the bytecode generator's m_lexical_environment_register_stack was not updated to reflect this, so subsequent CreateLexicalEnvironment ops would parent themselves to the old (pre-variable-environment) lexical environment, skipping the variable environment entirely. This meant function declarations hoisted into the variable environment were invisible to closures created in the function body. Fix this by capturing the new lexical environment into a register after CreateVariableEnvironment and pushing it onto the environment register stack. This fixes a problem where https://tumblr.com/ wouldn't load the feed.
2026-02-12 11:33:34 +01:00
if (has_non_local_vars) {
LibJS/Bytecode: Make compilation use SharedFunctionInstanceData instead All the data we need for compilation is in SharedFunctionInstanceData, so we shouldn't depend on ECMAScriptFunctionObject. Allows NativeJavaScriptBackedFunction to compile bytecode.
2025-11-06 17:26:02 +00:00
emit<Op::CreateVariableEnvironment>(shared_function_instance_data.m_var_environment_bindings_count);
LibJS: Fix scoping of function declarations with destructured params When a function has parameter expressions (e.g. destructured params with defaults), CreateVariableEnvironment creates a separate variable environment for function declarations and sets it as the current lexical environment at runtime. However, the bytecode generator's m_lexical_environment_register_stack was not updated to reflect this, so subsequent CreateLexicalEnvironment ops would parent themselves to the old (pre-variable-environment) lexical environment, skipping the variable environment entirely. This meant function declarations hoisted into the variable environment were invisible to closures created in the function body. Fix this by capturing the new lexical environment into a register after CreateVariableEnvironment and pushing it onto the environment register stack. This fixes a problem where https://tumblr.com/ wouldn't load the feed.
2026-02-12 11:33:34 +01:00
auto variable_environment = allocate_register();
emit<Op::GetLexicalEnvironment>(variable_environment);
m_lexical_environment_register_stack.append(variable_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: Pre-compute ScopeNode queries in SharedFunctionInstanceData Pre-compute the data that emit_function_declaration_instantiation previously obtained by querying ScopeNode methods at codegen time: - m_has_scope_body: whether ecmascript_code is a ScopeNode - m_has_non_local_lexical_declarations: from ScopeNode query - m_lexical_bindings: non-local lexically-scoped identifier names and their constant-declaration status After this change, emit_function_declaration_instantiation no longer casts m_ecmascript_code to ScopeNode or calls any ScopeNode methods.
2026-02-11 01:10:40 +01:00
if (shared_function_instance_data.m_has_scope_body) {
LibJS: Replace VariableNameToInitialize with value-type VarBinding Replace VariableNameToInitialize (which holds Identifier const&) with a VarBinding struct that stores pre-extracted values: name, local index, parameter_binding, and function_name. This removes a reference to AST Identifier nodes from SharedFunctionInstanceData, allowing the AST to be freed after compilation.
2026-02-11 01:06:58 +01:00
for (auto const& var : shared_function_instance_data.m_var_names_to_initialize_binding) {
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 initial_value = allocate_register();
LibJS: Replace VariableNameToInitialize with value-type VarBinding Replace VariableNameToInitialize (which holds Identifier const&) with a VarBinding struct that stores pre-extracted values: name, local index, parameter_binding, and function_name. This removes a reference to AST Identifier nodes from SharedFunctionInstanceData, allowing the AST to be freed after compilation.
2026-02-11 01:06:58 +01:00
if (!var.parameter_binding || var.function_name) {
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
emit<Op::Mov>(initial_value, add_constant(js_undefined()));
} else {
LibJS: Replace VariableNameToInitialize with value-type VarBinding Replace VariableNameToInitialize (which holds Identifier const&) with a VarBinding struct that stores pre-extracted values: name, local index, parameter_binding, and function_name. This removes a reference to AST Identifier nodes from SharedFunctionInstanceData, allowing the AST to be freed after compilation.
2026-02-11 01:06:58 +01:00
if (var.local.is_variable() || var.local.is_argument()) {
emit<Op::Mov>(initial_value, local(var.local));
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
} else {
LibJS: Replace VariableNameToInitialize with value-type VarBinding Replace VariableNameToInitialize (which holds Identifier const&) with a VarBinding struct that stores pre-extracted values: name, local index, parameter_binding, and function_name. This removes a reference to AST Identifier nodes from SharedFunctionInstanceData, allowing the AST to be freed after compilation.
2026-02-11 01:06:58 +01:00
emit<Op::GetBinding>(initial_value, intern_identifier(var.name));
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
}
}
LibJS: Replace VariableNameToInitialize with value-type VarBinding Replace VariableNameToInitialize (which holds Identifier const&) with a VarBinding struct that stores pre-extracted values: name, local index, parameter_binding, and function_name. This removes a reference to AST Identifier nodes from SharedFunctionInstanceData, allowing the AST to be freed after compilation.
2026-02-11 01:06:58 +01:00
if (var.local.is_variable() || var.local.is_argument()) {
emit<Op::Mov>(local(var.local), initial_value);
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
} else {
LibJS: Replace VariableNameToInitialize with value-type VarBinding Replace VariableNameToInitialize (which holds Identifier const&) with a VarBinding struct that stores pre-extracted values: name, local index, parameter_binding, and function_name. This removes a reference to AST Identifier nodes from SharedFunctionInstanceData, allowing the AST to be freed after compilation.
2026-02-11 01:06:58 +01:00
auto intern_id = intern_identifier(var.name);
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
emit<Op::CreateVariable>(intern_id, Op::EnvironmentMode::Var, false, false, false);
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
emit<Op::InitializeVariableBinding>(intern_id, initial_value);
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
LibJS: Pre-compute ScopeNode queries in SharedFunctionInstanceData Pre-compute the data that emit_function_declaration_instantiation previously obtained by querying ScopeNode methods at codegen time: - m_has_scope_body: whether ecmascript_code is a ScopeNode - m_has_non_local_lexical_declarations: from ScopeNode query - m_lexical_bindings: non-local lexically-scoped identifier names and their constant-declaration status After this change, emit_function_declaration_instantiation no longer casts m_ecmascript_code to ScopeNode or calls any ScopeNode methods.
2026-02-11 01:10:40 +01:00
if (!shared_function_instance_data.m_strict && shared_function_instance_data.m_has_scope_body) {
LibJS/Bytecode: Make compilation use SharedFunctionInstanceData instead All the data we need for compilation is in SharedFunctionInstanceData, so we shouldn't depend on ECMAScriptFunctionObject. Allows NativeJavaScriptBackedFunction to compile bytecode.
2025-11-06 17:26:02 +00:00
for (auto const& function_name : shared_function_instance_data.m_function_names_to_initialize_binding) {
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 intern_id = intern_identifier(function_name);
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
emit<Op::CreateVariable>(intern_id, Op::EnvironmentMode::Var, false, false, false);
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
emit<Op::InitializeVariableBinding>(intern_id, add_constant(js_undefined()));
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: Make compilation use SharedFunctionInstanceData instead All the data we need for compilation is in SharedFunctionInstanceData, so we shouldn't depend on ECMAScriptFunctionObject. Allows NativeJavaScriptBackedFunction to compile bytecode.
2025-11-06 17:26:02 +00:00
if (!shared_function_instance_data.m_strict) {
LibJS: Pre-compute ScopeNode queries in SharedFunctionInstanceData Pre-compute the data that emit_function_declaration_instantiation previously obtained by querying ScopeNode methods at codegen time: - m_has_scope_body: whether ecmascript_code is a ScopeNode - m_has_non_local_lexical_declarations: from ScopeNode query - m_lexical_bindings: non-local lexically-scoped identifier names and their constant-declaration status After this change, emit_function_declaration_instantiation no longer casts m_ecmascript_code to ScopeNode or calls any ScopeNode methods.
2026-02-11 01:10:40 +01:00
if (shared_function_instance_data.m_has_non_local_lexical_declarations) {
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
auto parent_environment = m_lexical_environment_register_stack.last();
auto new_environment = allocate_register();
emit<Op::CreateLexicalEnvironment>(new_environment, parent_environment, shared_function_instance_data.m_lex_environment_bindings_count);
m_lexical_environment_register_stack.append(new_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: Pre-compute ScopeNode queries in SharedFunctionInstanceData Pre-compute the data that emit_function_declaration_instantiation previously obtained by querying ScopeNode methods at codegen time: - m_has_scope_body: whether ecmascript_code is a ScopeNode - m_has_non_local_lexical_declarations: from ScopeNode query - m_lexical_bindings: non-local lexically-scoped identifier names and their constant-declaration status After this change, emit_function_declaration_instantiation no longer casts m_ecmascript_code to ScopeNode or calls any ScopeNode methods.
2026-02-11 01:10:40 +01:00
for (auto const& binding : shared_function_instance_data.m_lexical_bindings) {
emit<Op::CreateVariable>(intern_identifier(binding.name),
Op::EnvironmentMode::Lexical,
binding.is_constant,
false,
binding.is_constant);
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: Replace m_functions_to_initialize with pre-created data Replace Vector<FunctionDeclaration const&> with a FunctionToInitialize struct that stores a pre-created SharedFunctionInstanceData, function name, and local index. The SharedFunctionInstanceData for each hoisted function is created eagerly during the parent's construction, removing the need to reference FunctionDeclaration AST nodes after construction.
2026-02-11 01:08:21 +01:00
for (auto const& function_to_initialize : shared_function_instance_data.m_functions_to_initialize) {
auto data_index = register_shared_function_data(function_to_initialize.shared_data);
LibJS: Pre-create SharedFunctionInstanceData in NewFunction Replace the FunctionNode const& stored on the NewFunction bytecode instruction with an index into a table of pre-created SharedFunctionInstanceData objects on the Executable. During bytecode compilation, we now eagerly create SharedFunctionInstanceData for each function that will be instantiated by NewFunction, and store it on both the FunctionNode (for caching) and the Executable (for GC tracing). At runtime, NewFunction simply looks up the SharedFunctionInstanceData by index and calls create_from_function_data() directly, bypassing the AST entirely. This removes one of the main reasons the AST had to stay alive after compilation. The instantiate_ordinary_function_expression() helper in Interpreter.cpp is removed as its non-trivial code path (creating a scope for named function expressions) was dead code -- it was only called when !has_name(), so the has_own_name branch never executed.
2026-02-10 23:02:46 +01:00
LibJS: Replace m_functions_to_initialize with pre-created data Replace Vector<FunctionDeclaration const&> with a FunctionToInitialize struct that stores a pre-created SharedFunctionInstanceData, function name, and local index. The SharedFunctionInstanceData for each hoisted function is created eagerly during the parent's construction, removing the need to reference FunctionDeclaration AST nodes after construction.
2026-02-11 01:08:21 +01:00
if (function_to_initialize.local.is_variable() || function_to_initialize.local.is_argument()) {
emit<Op::NewFunction>(local(function_to_initialize.local), data_index, OptionalNone {}, OptionalNone {});
set_local_initialized(function_to_initialize.local);
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
} else {
LibJS: Put newly instantiated functions into locals more efficiently - Don't allocate a separate register, store directly into the local. - Mark the local as initialized to avoid emitting TDZ checks.
2025-03-27 14:44:04 +00:00
auto function = allocate_register();
LibJS: Pre-create SharedFunctionInstanceData in NewFunction Replace the FunctionNode const& stored on the NewFunction bytecode instruction with an index into a table of pre-created SharedFunctionInstanceData objects on the Executable. During bytecode compilation, we now eagerly create SharedFunctionInstanceData for each function that will be instantiated by NewFunction, and store it on both the FunctionNode (for caching) and the Executable (for GC tracing). At runtime, NewFunction simply looks up the SharedFunctionInstanceData by index and calls create_from_function_data() directly, bypassing the AST entirely. This removes one of the main reasons the AST had to stay alive after compilation. The instantiate_ordinary_function_expression() helper in Interpreter.cpp is removed as its non-trivial code path (creating a scope for named function expressions) was dead code -- it was only called when !has_name(), so the has_own_name branch never executed.
2026-02-10 23:02:46 +01:00
emit<Op::NewFunction>(function, data_index, OptionalNone {}, OptionalNone {});
LibJS: Replace m_functions_to_initialize with pre-created data Replace Vector<FunctionDeclaration const&> with a FunctionToInitialize struct that stores a pre-created SharedFunctionInstanceData, function name, and local index. The SharedFunctionInstanceData for each hoisted function is created eagerly during the parent's construction, removing the need to reference FunctionDeclaration AST nodes after construction.
2026-02-11 01:08:21 +01:00
emit<Op::SetVariableBinding>(intern_identifier(function_to_initialize.name), 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
}
}
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
GC::Ref<Executable> Generator::compile(VM& vm, ASTNode const& node, FunctionKind enclosing_function_kind, GC::Ptr<SharedFunctionInstanceData const> shared_function_instance_data, MustPropagateCompletion must_propagate_completion, BuiltinAbstractOperationsEnabled builtin_abstract_operations_enabled, Vector<LocalVariable> local_variable_names)
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: Introduce NativeJavaScriptBackedFunction This hosts the ability to compile and run JavaScript to implement native functions. This is particularly useful for any native function that is not a normal function, for example async functions such as Array.fromAsync, which require yielding. These functions are not allowed to observe anything from outside their environment. Any global identifiers will instead be assumed to be a reference to an abstract operation or a constant. The generator will inject the appropriate bytecode if the name of the global identifier matches a known name. Anything else will cause a code generation error.
2025-11-06 19:00:36 +00:00
Generator generator(vm, shared_function_instance_data, must_propagate_completion, builtin_abstract_operations_enabled);
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
if (is<Program>(node))
generator.m_strict = static_cast<Program const&>(node).is_strict_mode() ? Strict::Yes : Strict::No;
else if (is<FunctionBody>(node))
generator.m_strict = static_cast<FunctionBody const&>(node).in_strict_mode() ? Strict::Yes : Strict::No;
else if (is<FunctionDeclaration>(node))
generator.m_strict = static_cast<FunctionDeclaration const&>(node).is_strict_mode() ? Strict::Yes : Strict::No;
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
generator.m_local_variables = local_variable_names;
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: 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
generator.switch_to_basic_block(generator.make_block());
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
SourceLocationScope scope(generator, node);
LibJS: Implement async functions as generator functions in BC mode This applies a simple transformation, and adds a simple wrapper that translates the generator interface to the async function interface.
2021-11-11 00:46:07 +03:30
generator.m_enclosing_function_kind = enclosing_function_kind;
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
if (generator.is_in_async_function() && !generator.is_in_generator_function()) {
// Immediately yield with no value.
auto& start_block = generator.make_block();
generator.emit<Bytecode::Op::Yield>(Label { start_block }, generator.add_constant(js_undefined()));
generator.switch_to_basic_block(start_block);
// NOTE: This doesn't have to handle received throw/return completions, as GeneratorObject::resume_abrupt
// will not enter the generator from the SuspendedStart state and immediately completes the generator.
}
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
// NOTE: We eagerly initialize the saved lexical environment register here,
// before any AST codegen runs, so that GetLexicalEnvironment is emitted
// at the function entry point, dominating all uses.
generator.ensure_lexical_environment_register_initialized();
LibJS/Bytecode: Make compilation use SharedFunctionInstanceData instead All the data we need for compilation is in SharedFunctionInstanceData, so we shouldn't depend on ECMAScriptFunctionObject. Allows NativeJavaScriptBackedFunction to compile bytecode.
2025-11-06 17:26:02 +00:00
if (shared_function_instance_data)
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
generator.emit_function_declaration_instantiation(*shared_function_instance_data);
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 (generator.is_in_generator_function()) {
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
// Immediately yield with no value.
auto& start_block = generator.make_block();
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
generator.emit<Bytecode::Op::Yield>(Label { start_block }, generator.add_constant(js_undefined()));
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
generator.switch_to_basic_block(start_block);
LibJS: Perform received abrupt generator completions in the generator Previously, throw and return completions would not be executed inside the generator. This is incorrect, as throw and return need to perform unwinds which can potentially execute more code inside the generator, such as finally blocks. This is done by also passing the completion type alongside the passed in value. The continuation block will immediately extract and type and value and perform the appropriate operation for the given type. For normal completions, this is continuing as normal. For throw completions, it will perform `throw <value>`. For return completions, it will perform `return <value>`, which is a `Yield return` in this case due to being inside a generator. This also refactors GeneratorObject to properly send across the completion type and value to the generator inside of trying to operate on the completions itself. This is a prerequisite for yield*, as it performs special iterator operations when receiving a throw/return completion and does not complete the generator like the regular yield would. There's still more work to be done to make GeneratorObject::execute be closer to the spec. It's mostly a restructuring of the existing GeneratorObject::next_impl.
2022-11-25 23:14:08 +00:00
// NOTE: This doesn't have to handle received throw/return completions, as GeneratorObject::resume_abrupt
// will not enter the generator from the SuspendedStart state and immediately completes the generator.
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
}
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: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto last_value = node.generate_bytecode(generator);
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 (!generator.current_block().is_terminated() && last_value.has_value()) {
generator.emit<Bytecode::Op::End>(last_value.value());
}
LibJS: Implement async functions as generator functions in BC mode This applies a simple transformation, and adds a simple wrapper that translates the generator interface to the async function interface.
2021-11-11 00:46:07 +03:30
if (generator.is_in_generator_or_async_function()) {
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
// Terminate all unterminated blocks with yield return
for (auto& block : generator.m_root_basic_blocks) {
Everywhere: Stop using NonnullOwnPtrVector Same as NonnullRefPtrVector: weird semantics, questionable benefits.
2023-03-06 17:16:25 +01:00
if (block->is_terminated())
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
continue;
Everywhere: Stop using NonnullOwnPtrVector Same as NonnullRefPtrVector: weird semantics, questionable benefits.
2023-03-06 17:16:25 +01:00
generator.switch_to_basic_block(*block);
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
generator.emit_return<Bytecode::Op::Yield>(generator.add_constant(js_undefined()));
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
}
}
LibJS/Bytecode: Determine strict mode on an executable basis An executable is generated for the top-level script and for each function. Strict mode can only be changed with the first statement of the top-level script and each function, which corresponds directly to Executable.
2022-07-17 18:56:36 +01: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
size_t size_needed = 0;
for (auto& block : generator.m_root_basic_blocks) {
size_needed += block->size();
}
Vector<u8> bytecode;
bytecode.ensure_capacity(size_needed);
Vector<size_t> basic_block_start_offsets;
basic_block_start_offsets.ensure_capacity(generator.m_root_basic_blocks.size());
HashMap<BasicBlock const*, size_t> block_offsets;
Vector<size_t> label_offsets;
struct UnlinkedExceptionHandlers {
size_t start_offset;
size_t end_offset;
BasicBlock const* handler;
};
Vector<UnlinkedExceptionHandlers> unlinked_exception_handlers;
LibJS: Replace source map HashMap with sorted Vector Bytecode source map entries are always added in order of increasing bytecode offset, and lookups only happen during error handling (a cold path). This makes a sorted vector with binary search a better fit than a hash map. This change reduces memory overhead and speeds up bytecode generation by avoiding hash table operations during compilation. Lookups remain fast via binary search, and since source_range_at() is only called when generating stack traces, the O(log n) lookup is acceptable.
2026-01-26 17:51:53 +01:00
Vector<SourceMapEntry> source_map;
LibJS/Bytecode: Keep instruction source mappings in Executable Instead of storing source offsets with each instruction, we now keep them in a side table in Executable. This shrinks each instruction by 8 bytes, further improving locality.
2024-05-06 07:51:14 +02:00
LibJS/Bytecode: Move bytecode operand rewriting to a separate pass This way we don't have to do it whenever performing some kind of instruction rewrite.
2024-06-01 10:19:28 +02:00
Optional<ScopedOperand> undefined_constant;
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 (auto& block : generator.m_root_basic_blocks) {
if (!block->is_terminated()) {
// NOTE: We must ensure that the "undefined" constant, which will be used by the not yet
// emitted End instruction, is taken into account while shifting local operands by the
// number of constants.
LibJS/Bytecode: Move bytecode operand rewriting to a separate pass This way we don't have to do it whenever performing some kind of instruction rewrite.
2024-06-01 10:19:28 +02:00
undefined_constant = generator.add_constant(js_undefined());
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
break;
}
}
auto number_of_registers = generator.m_next_register;
auto number_of_constants = generator.m_constants.size();
LibJS: Skip initializing constant slots in ExecutionContext Every function call allocates an ExecutionContext with a trailing array of Values for registers, locals, constants, and arguments. Previously, the constructor would initialize all slots to js_special_empty_value(), but constant slots were then immediately overwritten by the interpreter copying in values from the Executable before execution began. To eliminate this redundant initialization, we rearrange the layout from [registers | constants | locals] to [registers | locals | constants]. This groups registers and locals together at the front, allowing us to initialize only those slots while leaving constant slots uninitialized until they're populated with their actual values. This reduces the per-call initialization cost from O(registers + locals + constants) to O(registers + locals). Also tightens up the types involved (size_t -> u32) and adds VERIFYs to guard against overflow when computing the combined slot counts, and to ensure the total fits within the 29-bit operand index field.
2026-01-18 23:17:10 +01:00
auto number_of_locals = local_variable_names.size();
u32 max_argument_index = 0;
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: Move bytecode operand rewriting to a separate pass This way we don't have to do it whenever performing some kind of instruction rewrite.
2024-06-01 10:19:28 +02:00
// Pass: Rewrite the bytecode to use the correct register and constant indices.
for (auto& block : generator.m_root_basic_blocks) {
Bytecode::InstructionStreamIterator it(block->instruction_stream());
while (!it.at_end()) {
auto& instruction = const_cast<Instruction&>(*it);
LibJS: Skip initializing constant slots in ExecutionContext Every function call allocates an ExecutionContext with a trailing array of Values for registers, locals, constants, and arguments. Previously, the constructor would initialize all slots to js_special_empty_value(), but constant slots were then immediately overwritten by the interpreter copying in values from the Executable before execution began. To eliminate this redundant initialization, we rearrange the layout from [registers | constants | locals] to [registers | locals | constants]. This groups registers and locals together at the front, allowing us to initialize only those slots while leaving constant slots uninitialized until they're populated with their actual values. This reduces the per-call initialization cost from O(registers + locals + constants) to O(registers + locals). Also tightens up the types involved (size_t -> u32) and adds VERIFYs to guard against overflow when computing the combined slot counts, and to ensure the total fits within the 29-bit operand index field.
2026-01-18 23:17:10 +01:00
// NB: The layout in ExecutionContext is: [registers | locals | constants | arguments]
instruction.visit_operands([number_of_registers, number_of_constants, number_of_locals, &max_argument_index](Operand& operand) {
LibJS/Bytecode: Move bytecode operand rewriting to a separate pass This way we don't have to do it whenever performing some kind of instruction rewrite.
2024-06-01 10:19:28 +02:00
switch (operand.type()) {
case Operand::Type::Register:
break;
case Operand::Type::Local:
LibJS: Skip initializing constant slots in ExecutionContext Every function call allocates an ExecutionContext with a trailing array of Values for registers, locals, constants, and arguments. Previously, the constructor would initialize all slots to js_special_empty_value(), but constant slots were then immediately overwritten by the interpreter copying in values from the Executable before execution began. To eliminate this redundant initialization, we rearrange the layout from [registers | constants | locals] to [registers | locals | constants]. This groups registers and locals together at the front, allowing us to initialize only those slots while leaving constant slots uninitialized until they're populated with their actual values. This reduces the per-call initialization cost from O(registers + locals + constants) to O(registers + locals). Also tightens up the types involved (size_t -> u32) and adds VERIFYs to guard against overflow when computing the combined slot counts, and to ensure the total fits within the 29-bit operand index field.
2026-01-18 23:17:10 +01:00
operand.offset_index_by(number_of_registers);
LibJS/Bytecode: Move bytecode operand rewriting to a separate pass This way we don't have to do it whenever performing some kind of instruction rewrite.
2024-06-01 10:19:28 +02:00
break;
case Operand::Type::Constant:
LibJS: Skip initializing constant slots in ExecutionContext Every function call allocates an ExecutionContext with a trailing array of Values for registers, locals, constants, and arguments. Previously, the constructor would initialize all slots to js_special_empty_value(), but constant slots were then immediately overwritten by the interpreter copying in values from the Executable before execution began. To eliminate this redundant initialization, we rearrange the layout from [registers | constants | locals] to [registers | locals | constants]. This groups registers and locals together at the front, allowing us to initialize only those slots while leaving constant slots uninitialized until they're populated with their actual values. This reduces the per-call initialization cost from O(registers + locals + constants) to O(registers + locals). Also tightens up the types involved (size_t -> u32) and adds VERIFYs to guard against overflow when computing the combined slot counts, and to ensure the total fits within the 29-bit operand index field.
2026-01-18 23:17:10 +01:00
operand.offset_index_by(number_of_registers + number_of_locals);
LibJS/Bytecode: Move bytecode operand rewriting to a separate pass This way we don't have to do it whenever performing some kind of instruction rewrite.
2024-06-01 10:19:28 +02: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:
LibJS: Skip initializing constant slots in ExecutionContext Every function call allocates an ExecutionContext with a trailing array of Values for registers, locals, constants, and arguments. Previously, the constructor would initialize all slots to js_special_empty_value(), but constant slots were then immediately overwritten by the interpreter copying in values from the Executable before execution began. To eliminate this redundant initialization, we rearrange the layout from [registers | constants | locals] to [registers | locals | constants]. This groups registers and locals together at the front, allowing us to initialize only those slots while leaving constant slots uninitialized until they're populated with their actual values. This reduces the per-call initialization cost from O(registers + locals + constants) to O(registers + locals). Also tightens up the types involved (size_t -> u32) and adds VERIFYs to guard against overflow when computing the combined slot counts, and to ensure the total fits within the 29-bit operand index field.
2026-01-18 23:17:10 +01:00
max_argument_index = max(max_argument_index, operand.index());
operand.offset_index_by(number_of_registers + number_of_locals + number_of_constants);
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
break;
LibJS/Bytecode: Move bytecode operand rewriting to a separate pass This way we don't have to do it whenever performing some kind of instruction rewrite.
2024-06-01 10:19:28 +02:00
default:
VERIFY_NOT_REACHED();
}
});
++it;
}
}
// Also rewrite the `undefined` constant if we have one for inserting End.
if (undefined_constant.has_value())
LibJS: Skip initializing constant slots in ExecutionContext Every function call allocates an ExecutionContext with a trailing array of Values for registers, locals, constants, and arguments. Previously, the constructor would initialize all slots to js_special_empty_value(), but constant slots were then immediately overwritten by the interpreter copying in values from the Executable before execution began. To eliminate this redundant initialization, we rearrange the layout from [registers | constants | locals] to [registers | locals | constants]. This groups registers and locals together at the front, allowing us to initialize only those slots while leaving constant slots uninitialized until they're populated with their actual values. This reduces the per-call initialization cost from O(registers + locals + constants) to O(registers + locals). Also tightens up the types involved (size_t -> u32) and adds VERIFYs to guard against overflow when computing the combined slot counts, and to ensure the total fits within the 29-bit operand index field.
2026-01-18 23:17:10 +01:00
undefined_constant.value().operand().offset_index_by(number_of_registers + number_of_locals);
LibJS/Bytecode: Move bytecode operand rewriting to a separate pass This way we don't have to do it whenever performing some kind of instruction rewrite.
2024-06-01 10:19:28 +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
for (auto& block : generator.m_root_basic_blocks) {
basic_block_start_offsets.append(bytecode.size());
LibJS: Collapse handler/finalizer into single exception handler target After replacing the runtime unwind context stack with explicit completion records for try/finally dispatch, the distinction between "handler" (catch) and "finalizer" (finally) in the exception handler table is no longer meaningful at runtime. handle_exception() checked handler first, then finalizer, but they did the exact same thing (set the PC). When both were present, the finalizer was dead code. Collapse both fields into a single handler_offset (now non-optional, since an entry always has a target), remove the finalizer concept from BasicBlock, UnwindContext, and ExceptionHandlers, and simplify handle_exception() to a direct assignment.
2026-02-09 12:08:49 +01:00
if (block->handler()) {
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
unlinked_exception_handlers.append({
.start_offset = bytecode.size(),
.end_offset = 0,
.handler = block->handler(),
});
}
block_offsets.set(block.ptr(), bytecode.size());
LibJS/Bytecode: Keep instruction source mappings in Executable Instead of storing source offsets with each instruction, we now keep them in a side table in Executable. This shrinks each instruction by 8 bytes, further improving locality.
2024-05-06 07:51:14 +02:00
LibJS: Replace source map HashMap with sorted Vector Bytecode source map entries are always added in order of increasing bytecode offset, and lookups only happen during error handling (a cold path). This makes a sorted vector with binary search a better fit than a hash map. This change reduces memory overhead and speeds up bytecode generation by avoiding hash table operations during compilation. Lookups remain fast via binary search, and since source_range_at() is only called when generating stack traces, the O(log n) lookup is acceptable.
2026-01-26 17:51:53 +01:00
for (auto const& entry : block->source_map()) {
VERIFY(bytecode.size() <= NumericLimits<u32>::max());
source_map.append({ static_cast<u32>(bytecode.size()) + entry.bytecode_offset, entry.source_record });
LibJS/Bytecode: Keep instruction source mappings in Executable Instead of storing source offsets with each instruction, we now keep them in a side table in Executable. This shrinks each instruction by 8 bytes, further improving locality.
2024-05-06 07:51:14 +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
Bytecode::InstructionStreamIterator it(block->instruction_stream());
while (!it.at_end()) {
auto& instruction = const_cast<Instruction&>(*it);
LibJS/Bytecode: Elide jumps that land in the very next block Jumping to the next block is effectively a no-op, so let's save time and space by just not emitting those jumps.
2024-05-06 09:33:53 +02:00
if (instruction.type() == Instruction::Type::Jump) {
auto& jump = static_cast<Bytecode::Op::Jump&>(instruction);
LibJS/Bytecode: Rewrite Jump-to-Return-or-End as just Return or End Instead of wasting time jumping to a shared Return or End instruction, we can also emit a Return or End directly in many cases.
2024-06-01 10:20:12 +02:00
// OPTIMIZATION: Don't emit jumps that just jump to the next block.
LibJS/Bytecode: Elide jumps that land in the very next block Jumping to the next block is effectively a no-op, so let's save time and space by just not emitting those jumps.
2024-05-06 09:33:53 +02:00
if (jump.target().basic_block_index() == block->index() + 1) {
if (basic_block_start_offsets.last() == bytecode.size()) {
// This block is empty, just skip it.
basic_block_start_offsets.take_last();
}
++it;
continue;
}
LibJS/Bytecode: Rewrite Jump-to-Return-or-End as just Return or End Instead of wasting time jumping to a shared Return or End instruction, we can also emit a Return or End directly in many cases.
2024-06-01 10:20:12 +02:00
// OPTIMIZATION: For jumps to a return-or-end-only block, we can emit a `Return` or `End` directly instead.
auto& target_block = *generator.m_root_basic_blocks[jump.target().basic_block_index()];
if (target_block.is_terminated()) {
auto target_instruction_iterator = InstructionStreamIterator { target_block.instruction_stream() };
auto& target_instruction = *target_instruction_iterator;
if (target_instruction.type() == Instruction::Type::Return) {
auto& return_instruction = static_cast<Bytecode::Op::Return const&>(target_instruction);
Op::Return return_op(return_instruction.value());
bytecode.append(reinterpret_cast<u8 const*>(&return_op), return_op.length());
++it;
continue;
}
if (target_instruction.type() == Instruction::Type::End) {
auto& return_instruction = static_cast<Bytecode::Op::End const&>(target_instruction);
Op::End end_op(return_instruction.value());
bytecode.append(reinterpret_cast<u8 const*>(&end_op), end_op.length());
++it;
continue;
}
}
LibJS/Bytecode: Elide jumps that land in the very next block Jumping to the next block is effectively a no-op, so let's save time and space by just not emitting those jumps.
2024-05-06 09:33:53 +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
// OPTIMIZATION: For `JumpIf` where one of the targets is the very next block,
// we can emit a `JumpTrue` or `JumpFalse` (to the other block) instead.
if (instruction.type() == Instruction::Type::JumpIf) {
auto& jump = static_cast<Bytecode::Op::JumpIf&>(instruction);
if (jump.true_target().basic_block_index() == block->index() + 1) {
Op::JumpFalse jump_false(jump.condition(), Label { jump.false_target() });
auto& label = jump_false.target();
size_t label_offset = bytecode.size() + (bit_cast<FlatPtr>(&label) - bit_cast<FlatPtr>(&jump_false));
label_offsets.append(label_offset);
bytecode.append(reinterpret_cast<u8 const*>(&jump_false), jump_false.length());
++it;
continue;
}
if (jump.false_target().basic_block_index() == block->index() + 1) {
Op::JumpTrue jump_true(jump.condition(), Label { jump.true_target() });
auto& label = jump_true.target();
size_t label_offset = bytecode.size() + (bit_cast<FlatPtr>(&label) - bit_cast<FlatPtr>(&jump_true));
label_offsets.append(label_offset);
bytecode.append(reinterpret_cast<u8 const*>(&jump_true), jump_true.length());
++it;
continue;
}
}
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
instruction.visit_labels([&](Label& label) {
size_t label_offset = bytecode.size() + (bit_cast<FlatPtr>(&label) - bit_cast<FlatPtr>(&instruction));
label_offsets.append(label_offset);
});
bytecode.append(reinterpret_cast<u8 const*>(&instruction), instruction.length());
++it;
}
if (!block->is_terminated()) {
LibJS/Bytecode: Move bytecode operand rewriting to a separate pass This way we don't have to do it whenever performing some kind of instruction rewrite.
2024-06-01 10:19:28 +02:00
Op::End end(*undefined_constant);
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
bytecode.append(reinterpret_cast<u8 const*>(&end), end.length());
}
LibJS: Collapse handler/finalizer into single exception handler target After replacing the runtime unwind context stack with explicit completion records for try/finally dispatch, the distinction between "handler" (catch) and "finalizer" (finally) in the exception handler table is no longer meaningful at runtime. handle_exception() checked handler first, then finalizer, but they did the exact same thing (set the PC). When both were present, the finalizer was dead code. Collapse both fields into a single handler_offset (now non-optional, since an entry always has a target), remove the finalizer concept from BasicBlock, UnwindContext, and ExceptionHandlers, and simplify handle_exception() to a direct assignment.
2026-02-09 12:08:49 +01:00
if (block->handler()) {
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
unlinked_exception_handlers.last().end_offset = bytecode.size();
}
}
for (auto label_offset : label_offsets) {
auto& label = *reinterpret_cast<Label*>(bytecode.data() + label_offset);
LibJS/Bytecode: Store labels as basic block index during compilation Instead of storing a BasicBlock* and forcing the size of Label to be sizeof(BasicBlock*), we now store the basic block index as a u32. This means the final version of the bytecode is able to keep labels at sizeof(u32), shrinking the size of many instructions. :^)
2024-05-06 08:06:56 +02:00
auto* block = generator.m_root_basic_blocks[label.basic_block_index()].ptr();
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
label.set_address(block_offsets.get(block).value());
}
LibJS+LibWeb: Rename Heap::allocate_without_realm to Heap::allocate Now that the heap has no knowledge about a JavaScript realm and is purely for managing the memory of the heap, it does not make sense to name this function to say that it is a non-realm variant.
2024-11-14 06:13:46 +13:00
auto executable = vm.heap().allocate<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
move(bytecode),
LibJS: Make Executable ref-counted and let instruction iterator co-own it This ensures that the instruction stream pointed at by the instruction iterator remains valid as long as the iterator exists.
2023-10-03 08:18:10 +02:00
move(generator.m_identifier_table),
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
move(generator.m_property_key_table),
LibJS: Make Executable ref-counted and let instruction iterator co-own it This ensures that the instruction stream pointed at by the instruction iterator remains valid as long as the iterator exists.
2023-10-03 08:18:10 +02:00
move(generator.m_string_table),
move(generator.m_regex_table),
LibJS/Bytecode: Add constants table to Bytecode::Executable
2024-02-02 09:52:25 +01:00
move(generator.m_constants),
LibJS: Make Executable ref-counted and let instruction iterator co-own it This ensures that the instruction stream pointed at by the instruction iterator remains valid as long as the iterator exists.
2023-10-03 08:18:10 +02:00
node.source_code(),
generator.m_next_property_lookup_cache,
generator.m_next_global_variable_cache,
LibJS: Follow the spec more closely for tagged template literals This resolves a FIXME in its code generation, particularly for: - Caching the template object - Setting the correct property attributes - Freezing the resulting objects This allows archive.org to load, which uses the Lit library. The Lit library caches these template objects to determine if a template has changed, allowing it to determine to do a full template rerender or only partially update the rendering. Before, we would always cause a full rerender on update because we didn't return the same template object. This caused issues with archive.org's code, I believe particularly with its router library, where we would constantly detach and reattach nodes unexpectedly, ending up with the page content not being attached to the router's custom element.
2026-01-06 19:49:38 +00:00
generator.m_next_template_object_cache,
LibJS: Add shape caching for object literal instantiation When a function creates object literals with simple property names, we now cache the resulting shape after the first instantiation. On subsequent calls, we create the object with the cached shape directly and write property values at their known offsets. This avoids repeated shape transitions and property offset lookups for a common JavaScript pattern. The optimization uses two new bytecode instructions: - CacheObjectShape: Captures the final shape after object construction - InitObjectLiteralProperty: Writes properties using cached offsets Only "simple" object literals are optimized (string literal keys with simple value expressions). Complex cases like computed properties, getters/setters, and spread elements use the existing slow path. 3.4x speedup on a microbenchmark that repeatedly instantiates an object literal with 26 properties. Small progressions on various benchmarks.
2026-01-09 18:55:00 +01:00
generator.m_next_object_shape_cache,
LibJS: Make Executable ref-counted and let instruction iterator co-own it This ensures that the instruction stream pointed at by the instruction iterator remains valid as long as the iterator exists.
2023-10-03 08:18:10 +02:00
generator.m_next_register,
LibJS: Let bytecode instructions know whether they are in strict mode This commits puts the strict mode flag in the header of every bytecode instruction. This allows us to check for strict mode without looking at the currently running execution context.
2025-10-28 20:25:12 +01:00
generator.m_strict);
LibJS/Bytecode: Cache object own property accesses The instructions GetById and GetByIdWithThis now remember the last-seen Shape, and if we see the same object again, we reuse the property offset from last time without doing a new lookup. This allows us to use Object::get_direct(), bypassing the entire lookup machinery and saving lots of time. ~23% speed-up on Kraken/ai-astar.js :^)
2023-07-08 17:43:26 +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
Vector<Executable::ExceptionHandlers> linked_exception_handlers;
for (auto& unlinked_handler : unlinked_exception_handlers) {
auto start_offset = unlinked_handler.start_offset;
auto end_offset = unlinked_handler.end_offset;
LibJS: Collapse handler/finalizer into single exception handler target After replacing the runtime unwind context stack with explicit completion records for try/finally dispatch, the distinction between "handler" (catch) and "finalizer" (finally) in the exception handler table is no longer meaningful at runtime. handle_exception() checked handler first, then finalizer, but they did the exact same thing (set the PC). When both were present, the finalizer was dead code. Collapse both fields into a single handler_offset (now non-optional, since an entry always has a target), remove the finalizer concept from BasicBlock, UnwindContext, and ExceptionHandlers, and simplify handle_exception() to a direct assignment.
2026-02-09 12:08:49 +01:00
auto handler_offset = block_offsets.get(unlinked_handler.handler).value();
LibJS/Bytecode: Merge adjacent exception handlers For example, this: ``` Exception handlers: from 678 to 698 handler 658 finalizer 0 from 698 to 6f8 handler 658 finalizer 0 from 6f8 to 708 handler 658 finalizer 0 from 708 to 750 handler 658 finalizer 0 from 750 to 788 handler 658 finalizer 0 from 788 to 7a0 handler 658 finalizer 0 from 7a0 to 7a8 handler 658 finalizer 0 ``` Becomes: ``` Exception handlers: from 678 to 7a8 handler 658 finalizer 0 ```
2025-10-10 21:05:50 +01:00
auto maybe_exception_handler_to_merge_with = linked_exception_handlers.find_if([&](Executable::ExceptionHandlers const& exception_handler) {
LibJS: Collapse handler/finalizer into single exception handler target After replacing the runtime unwind context stack with explicit completion records for try/finally dispatch, the distinction between "handler" (catch) and "finalizer" (finally) in the exception handler table is no longer meaningful at runtime. handle_exception() checked handler first, then finalizer, but they did the exact same thing (set the PC). When both were present, the finalizer was dead code. Collapse both fields into a single handler_offset (now non-optional, since an entry always has a target), remove the finalizer concept from BasicBlock, UnwindContext, and ExceptionHandlers, and simplify handle_exception() to a direct assignment.
2026-02-09 12:08:49 +01:00
return exception_handler.end_offset == start_offset && exception_handler.handler_offset == handler_offset;
LibJS/Bytecode: Merge adjacent exception handlers For example, this: ``` Exception handlers: from 678 to 698 handler 658 finalizer 0 from 698 to 6f8 handler 658 finalizer 0 from 6f8 to 708 handler 658 finalizer 0 from 708 to 750 handler 658 finalizer 0 from 750 to 788 handler 658 finalizer 0 from 788 to 7a0 handler 658 finalizer 0 from 7a0 to 7a8 handler 658 finalizer 0 ``` Becomes: ``` Exception handlers: from 678 to 7a8 handler 658 finalizer 0 ```
2025-10-10 21:05:50 +01:00
});
if (!maybe_exception_handler_to_merge_with.is_end()) {
auto& exception_handler_to_merge_with = *maybe_exception_handler_to_merge_with;
exception_handler_to_merge_with.end_offset = end_offset;
} else {
LibJS: Collapse handler/finalizer into single exception handler target After replacing the runtime unwind context stack with explicit completion records for try/finally dispatch, the distinction between "handler" (catch) and "finalizer" (finally) in the exception handler table is no longer meaningful at runtime. handle_exception() checked handler first, then finalizer, but they did the exact same thing (set the PC). When both were present, the finalizer was dead code. Collapse both fields into a single handler_offset (now non-optional, since an entry always has a target), remove the finalizer concept from BasicBlock, UnwindContext, and ExceptionHandlers, and simplify handle_exception() to a direct assignment.
2026-02-09 12:08:49 +01:00
linked_exception_handlers.append({ start_offset, end_offset, handler_offset });
LibJS/Bytecode: Merge adjacent exception handlers For example, this: ``` Exception handlers: from 678 to 698 handler 658 finalizer 0 from 698 to 6f8 handler 658 finalizer 0 from 6f8 to 708 handler 658 finalizer 0 from 708 to 750 handler 658 finalizer 0 from 750 to 788 handler 658 finalizer 0 from 788 to 7a0 handler 658 finalizer 0 from 7a0 to 7a8 handler 658 finalizer 0 ``` Becomes: ``` Exception handlers: from 678 to 7a8 handler 658 finalizer 0 ```
2025-10-10 21:05:50 +01: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
}
quick_sort(linked_exception_handlers, [](auto const& a, auto const& b) {
return a.start_offset < b.start_offset;
});
executable->exception_handlers = move(linked_exception_handlers);
executable->basic_block_start_offsets = move(basic_block_start_offsets);
LibJS/Bytecode: Keep instruction source mappings in Executable Instead of storing source offsets with each instruction, we now keep them in a side table in Executable. This shrinks each instruction by 8 bytes, further improving locality.
2024-05-06 07:51:14 +02:00
executable->source_map = move(source_map);
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
executable->local_variable_names = move(local_variable_names);
LibJS: Pre-create SharedFunctionInstanceData in NewFunction Replace the FunctionNode const& stored on the NewFunction bytecode instruction with an index into a table of pre-created SharedFunctionInstanceData objects on the Executable. During bytecode compilation, we now eagerly create SharedFunctionInstanceData for each function that will be instantiated by NewFunction, and store it on both the FunctionNode (for caching) and the Executable (for GC tracing). At runtime, NewFunction simply looks up the SharedFunctionInstanceData by index and calls create_from_function_data() directly, bypassing the AST entirely. This removes one of the main reasons the AST had to stay alive after compilation. The instantiate_ordinary_function_expression() helper in Interpreter.cpp is removed as its non-trivial code path (creating a scope for named function expressions) was dead code -- it was only called when !has_name(), so the has_own_name branch never executed.
2026-02-10 23:02:46 +01:00
executable->shared_function_data.ensure_capacity(generator.m_shared_function_data.size());
for (auto& root : generator.m_shared_function_data)
executable->shared_function_data.append(root.ptr());
LibJS: Populate ClassBlueprint during codegen Build a ClassBlueprint from ClassExpression elements at codegen time: - Methods/getters/setters: register SharedFunctionInstanceData from the method's FunctionExpression - Field initializers with literal values (numbers, booleans, null, strings, negated numbers): store the value directly, avoiding function creation entirely - Field initializers with non-literal values: wrap in ClassFieldInitializerStatement and create SharedFunctionInstanceData - Static initializers: create SharedFunctionInstanceData from the function body - Constructor: register SharedFunctionInstanceData from the constructor's FunctionExpression Add public accessors to ClassMethod::function() and StaticInitializer::function_body() for codegen access. The blueprint is registered but not yet used by NewClass (dual path). No behavioral change.
2026-02-11 00:20:47 +01:00
executable->class_blueprints = move(generator.m_class_blueprints);
LibJS: Skip initializing constant slots in ExecutionContext Every function call allocates an ExecutionContext with a trailing array of Values for registers, locals, constants, and arguments. Previously, the constructor would initialize all slots to js_special_empty_value(), but constant slots were then immediately overwritten by the interpreter copying in values from the Executable before execution began. To eliminate this redundant initialization, we rearrange the layout from [registers | constants | locals] to [registers | locals | constants]. This groups registers and locals together at the front, allowing us to initialize only those slots while leaving constant slots uninitialized until they're populated with their actual values. This reduces the per-call initialization cost from O(registers + locals + constants) to O(registers + locals). Also tightens up the types involved (size_t -> u32) and adds VERIFYs to guard against overflow when computing the combined slot counts, and to ensure the total fits within the 29-bit operand index field.
2026-01-18 23:17:10 +01:00
// NB: Layout is [registers | locals | constants | arguments]
executable->local_index_base = number_of_registers;
VERIFY(!Checked<u32>::addition_would_overflow(number_of_registers, number_of_locals, number_of_constants));
executable->argument_index_base = number_of_registers + number_of_locals + number_of_constants;
// NB: Operand indices are stored in 29 bits, so the max operand index must fit.
VERIFY(!Checked<u32>::addition_would_overflow(executable->argument_index_base, max_argument_index));
VERIFY(executable->argument_index_base + max_argument_index <= 0x1FFFFFFFu);
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
executable->length_identifier = generator.m_length_identifier;
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: Skip initializing constant slots in ExecutionContext Every function call allocates an ExecutionContext with a trailing array of Values for registers, locals, constants, and arguments. Previously, the constructor would initialize all slots to js_special_empty_value(), but constant slots were then immediately overwritten by the interpreter copying in values from the Executable before execution began. To eliminate this redundant initialization, we rearrange the layout from [registers | constants | locals] to [registers | locals | constants]. This groups registers and locals together at the front, allowing us to initialize only those slots while leaving constant slots uninitialized until they're populated with their actual values. This reduces the per-call initialization cost from O(registers + locals + constants) to O(registers + locals). Also tightens up the types involved (size_t -> u32) and adds VERIFYs to guard against overflow when computing the combined slot counts, and to ensure the total fits within the 29-bit operand index field.
2026-01-18 23:17:10 +01:00
VERIFY(!Checked<u32>::addition_would_overflow(executable->number_of_registers, executable->local_variable_names.size()));
executable->registers_and_locals_count = executable->number_of_registers + executable->local_variable_names.size();
VERIFY(!Checked<u32>::addition_would_overflow(executable->registers_and_locals_count, executable->constants.size()));
executable->registers_and_locals_and_constants_count = executable->registers_and_locals_count + executable->constants.size();
// Sanity check: ensure offset computation values match Executable values.
VERIFY(number_of_registers == executable->number_of_registers);
VERIFY(number_of_locals == executable->local_variable_names.size());
VERIFY(number_of_constants == executable->constants.size());
LibJS: Precompute the number of regs/constants/locals in Executable Instead of doing it again on every call. Minor bump in call performance.
2025-10-30 00:09:09 +01:00
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
generator.m_finished = true;
LibJS: Make Executable ref-counted and let instruction iterator co-own it This ensures that the instruction stream pointed at by the instruction iterator remains valid as long as the iterator exists.
2023-10-03 08:18:10 +02:00
return executable;
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: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
GC::Ref<Executable> Generator::generate_from_ast_node(VM& vm, ASTNode const& node, FunctionKind enclosing_function_kind)
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
{
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
Vector<LocalVariable> local_variable_names;
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
if (is<ScopeNode>(node))
local_variable_names = static_cast<ScopeNode const&>(node).local_variables_names();
LibJS: Introduce NativeJavaScriptBackedFunction This hosts the ability to compile and run JavaScript to implement native functions. This is particularly useful for any native function that is not a normal function, for example async functions such as Array.fromAsync, which require yielding. These functions are not allowed to observe anything from outside their environment. Any global identifiers will instead be assumed to be a reference to an abstract operation or a constant. The generator will inject the appropriate bytecode if the name of the global identifier matches a known name. Anything else will cause a code generation error.
2025-11-06 19:00:36 +00:00
return compile(vm, node, enclosing_function_kind, {}, MustPropagateCompletion::Yes, BuiltinAbstractOperationsEnabled::No, move(local_variable_names));
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
GC::Ref<Executable> Generator::generate_from_function(VM& vm, GC::Ref<SharedFunctionInstanceData const> shared_function_instance_data, BuiltinAbstractOperationsEnabled builtin_abstract_operations_enabled)
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
{
LibJS: Clear compile-only data from SharedFunctionInstanceData After successful bytecode compilation, the m_functions_to_initialize and m_var_names_to_initialize_binding vectors are no longer needed as they are only consumed by emit_function_declaration_instantiation() during code generation. Add clear_compile_inputs() to release these vectors post-compile, and call it from both ECMAScriptFunctionObject::get_stack_frame_size() and NativeJavaScriptBackedFunction::bytecode_executable() after their respective lazy compilation succeeds. Also add a pre-compile assertion in Generator::generate_from_function() to verify we never try to compile the same function data twice, and a VERIFY in ECMAScriptFunctionObject::ecmascript_code() to guard against null dereference.
2026-02-10 22:21:23 +01:00
VERIFY(!shared_function_instance_data->m_executable);
LibJS: Introduce NativeJavaScriptBackedFunction This hosts the ability to compile and run JavaScript to implement native functions. This is particularly useful for any native function that is not a normal function, for example async functions such as Array.fromAsync, which require yielding. These functions are not allowed to observe anything from outside their environment. Any global identifiers will instead be assumed to be a reference to an abstract operation or a constant. The generator will inject the appropriate bytecode if the name of the global identifier matches a known name. Anything else will cause a code generation error.
2025-11-06 19:00:36 +00:00
return compile(vm, *shared_function_instance_data->m_ecmascript_code, shared_function_instance_data->m_kind, shared_function_instance_data, MustPropagateCompletion::No, builtin_abstract_operations_enabled, shared_function_instance_data->m_local_variables_names);
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 bytecode instruction handles" This reverts commit a01bd35c67e35e9f0e33f46bb3a4431e49af1b60. This broke simple programs like: function sum(a, b) { return a + b; } console.log(sum(1, 2));
2021-06-09 00:50:42 +02:00
void Generator::grow(size_t additional_size)
{
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
VERIFY(m_current_basic_block);
m_current_basic_block->grow(additional_size);
Revert "LibJS: Add bytecode instruction handles" This reverts commit a01bd35c67e35e9f0e33f46bb3a4431e49af1b60. This broke simple programs like: function sum(a, b) { return a + b; } console.log(sum(1, 2));
2021-06-09 00:50:42 +02:00
}
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
ScopedOperand Generator::allocate_register()
{
if (!m_free_registers.is_empty()) {
return ScopedOperand { *this, Operand { m_free_registers.take_last() } };
}
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
VERIFY(m_next_register != NumericLimits<u32>::max());
return ScopedOperand { *this, Operand { Register { m_next_register++ } } };
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
}
void Generator::free_register(Register reg)
{
m_free_registers.append(reg);
}
LibJS: Skip allocating locals for arguments that allowed to be local This allows us to get rid of instructions that move arguments to locals and allocate smaller JS::Value vector in ExecutionContext by reusing slots that were already allocated for arguments. With this change for following function: ```js function f(x, y) { return x + y; } ``` we now produce following bytecode: ``` [ 0] 0: Add dst:reg6, lhs:arg0, rhs:arg1 [ 10] Return value:reg6 ``` instead of: ``` [ 0] 0: GetArgument 0, dst:x~1 [ 10] GetArgument 1, dst:y~0 [ 20] Add dst:reg6, lhs:x~1, rhs:y~0 [ 30] Return value:reg6 ```
2025-04-25 17:10:47 +02:00
ScopedOperand Generator::local(Identifier::Local const& local)
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
{
LibJS: Skip allocating locals for arguments that allowed to be local This allows us to get rid of instructions that move arguments to locals and allocate smaller JS::Value vector in ExecutionContext by reusing slots that were already allocated for arguments. With this change for following function: ```js function f(x, y) { return x + y; } ``` we now produce following bytecode: ``` [ 0] 0: Add dst:reg6, lhs:arg0, rhs:arg1 [ 10] Return value:reg6 ``` instead of: ``` [ 0] 0: GetArgument 0, dst:x~1 [ 10] GetArgument 1, dst:y~0 [ 20] Add dst:reg6, lhs:x~1, rhs:y~0 [ 30] Return value:reg6 ```
2025-04-25 17:10:47 +02:00
if (local.is_variable())
return ScopedOperand { *this, Operand { Operand::Type::Local, static_cast<u32>(local.index) } };
return ScopedOperand { *this, Operand { Operand::Type::Argument, static_cast<u32>(local.index) } };
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: Remove #include <AST.h> from SharedFunctionInstanceData.h Extract FunctionParsingInsights into its own header and introduce FunctionLocal as a standalone mirror of Identifier::Local. This allows SharedFunctionInstanceData.h to avoid pulling in the full AST type hierarchy, reducing transitive include bloat. The AST.h include is kept in SharedFunctionInstanceData.cpp where it's needed for the constructor that accesses AST node types.
2026-02-11 01:20:54 +01:00
ScopedOperand Generator::local(FunctionLocal const& local)
{
if (local.is_variable())
return ScopedOperand { *this, Operand { Operand::Type::Local, static_cast<u32>(local.index) } };
return ScopedOperand { *this, Operand { Operand::Type::Argument, static_cast<u32>(local.index) } };
}
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Generator::SourceLocationScope::SourceLocationScope(Generator& generator, ASTNode const& node)
: m_generator(generator)
, m_previous_node(m_generator.m_current_ast_node)
{
m_generator.m_current_ast_node = &node;
}
Generator::SourceLocationScope::~SourceLocationScope()
{
m_generator.m_current_ast_node = m_previous_node;
}
LibJS: Collapse handler/finalizer into single exception handler target After replacing the runtime unwind context stack with explicit completion records for try/finally dispatch, the distinction between "handler" (catch) and "finalizer" (finally) in the exception handler table is no longer meaningful at runtime. handle_exception() checked handler first, then finalizer, but they did the exact same thing (set the PC). When both were present, the finalizer was dead code. Collapse both fields into a single handler_offset (now non-optional, since an entry always has a target), remove the finalizer concept from BasicBlock, UnwindContext, and ExceptionHandlers, and simplify handle_exception() to a direct assignment.
2026-02-09 12:08:49 +01:00
Generator::UnwindContext::UnwindContext(Generator& generator, Optional<Label> handler)
LibJS: Create static unwind mappings for `BasicBlock`s This is currently only used in the bytecode dump to annotate to where unwinds lead per block, but will be hooked up to the virtual machine in the next commit.
2023-10-19 23:18:54 +02:00
: m_generator(generator)
LibJS: Collapse handler/finalizer into single exception handler target After replacing the runtime unwind context stack with explicit completion records for try/finally dispatch, the distinction between "handler" (catch) and "finalizer" (finally) in the exception handler table is no longer meaningful at runtime. handle_exception() checked handler first, then finalizer, but they did the exact same thing (set the PC). When both were present, the finalizer was dead code. Collapse both fields into a single handler_offset (now non-optional, since an entry always has a target), remove the finalizer concept from BasicBlock, UnwindContext, and ExceptionHandlers, and simplify handle_exception() to a direct assignment.
2026-02-09 12:08:49 +01:00
, m_handler(handler)
LibJS: Create static unwind mappings for `BasicBlock`s This is currently only used in the bytecode dump to annotate to where unwinds lead per block, but will be hooked up to the virtual machine in the next commit.
2023-10-19 23:18:54 +02:00
, m_previous_context(m_generator.m_current_unwind_context)
{
m_generator.m_current_unwind_context = this;
}
Generator::UnwindContext::~UnwindContext()
{
VERIFY(m_generator.m_current_unwind_context == this);
m_generator.m_current_unwind_context = m_previous_context;
}
LibJS: Add basic support for "continue" in the bytecode VM Unlike the convoluted unwind-until-scope-type mechanism in the AST interpreter, "continue" maps to a simple Bytecode::Op::Jump here. :^) We know where to jump based on a stack of "continuable scopes" that we now maintain on the Bytecode::Generator as we go. Note that this only supports bare "continue", not continue-with-label.
2021-06-06 13:33:02 +02:00
Label Generator::nearest_continuable_scope() const
{
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
return m_continuable_scopes.last().bytecode_target;
LibJS: Add basic support for "continue" in the bytecode VM Unlike the convoluted unwind-until-scope-type mechanism in the AST interpreter, "continue" maps to a simple Bytecode::Op::Jump here. :^) We know where to jump based on a stack of "continuable scopes" that we now maintain on the Bytecode::Generator as we go. Note that this only supports bare "continue", not continue-with-label.
2021-06-06 13:33:02 +02:00
}
LibJS/Bytecode: Don't create empty lexical environments This patch stops emitting the BlockDeclarationInstantiation instruction when there are no locals, and no function declarations in the scope. We were spending 20% of CPU time on https://ventrella.com/Clusters/ just creating empty environments for no reason.
2024-05-11 13:25:08 +02:00
bool Generator::emit_block_declaration_instantiation(ScopeNode const& scope_node)
LibJS/Bytecode: Unwind environments before block terminating instruction When we reach a block terminating instruction (e.g. Break, Throw), we cannot generate anymore instructions after it. This would not allow us to leave any lexical/variable environments. This uses the mechanism introduced in ba9c49 to unwind environments when we encounter these instructions.
2022-03-14 02:34:01 +00:00
{
LibJS/Bytecode: Don't create empty lexical environments This patch stops emitting the BlockDeclarationInstantiation instruction when there are no locals, and no function declarations in the scope. We were spending 20% of CPU time on https://ventrella.com/Clusters/ just creating empty environments for no reason.
2024-05-11 13:25:08 +02:00
bool needs_block_declaration_instantiation = false;
MUST(scope_node.for_each_lexically_scoped_declaration([&](Declaration const& declaration) {
if (declaration.is_function_declaration()) {
needs_block_declaration_instantiation = true;
return;
}
MUST(declaration.for_each_bound_identifier([&](auto const& id) {
if (!id.is_local())
needs_block_declaration_instantiation = true;
}));
}));
if (!needs_block_declaration_instantiation)
return false;
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
auto parent_environment = m_lexical_environment_register_stack.last();
LibJS: Generate bytecode for the BlockDeclarationInstantiation AO This necessitated adding some new instructions for creating mutable and immutable bindings.
2025-10-25 14:06:48 +02:00
auto environment = allocate_register();
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
emit<Bytecode::Op::CreateLexicalEnvironment>(environment, parent_environment, 0);
m_lexical_environment_register_stack.append(environment);
LibJS/Bytecode: Leave BlockDeclarationInstantiation in C++ Instead of implementing this AO in bytecode, we now have an instruction for it that simply invokes the C++ implementation. This allows us to simplify Bytecode::Generator quite a bit by removing all the variable scope tracking.
2023-06-16 16:34:47 +02:00
start_boundary(BlockBoundaryType::LeaveLexicalEnvironment);
LibJS: Generate bytecode for the BlockDeclarationInstantiation AO This necessitated adding some new instructions for creating mutable and immutable bindings.
2025-10-25 14:06:48 +02:00
MUST(scope_node.for_each_lexically_scoped_declaration([&](Declaration const& declaration) {
auto is_constant_declaration = declaration.is_constant_declaration();
// NOTE: Due to the use of MUST with `create_immutable_binding` and `create_mutable_binding` below,
// an exception should not result from `for_each_bound_name`.
// a. For each element dn of the BoundNames of d, do
MUST(declaration.for_each_bound_identifier([&](Identifier const& identifier) {
if (identifier.is_local()) {
// NOTE: No need to create bindings for local variables as their values are not stored in an environment.
return;
}
auto const& name = identifier.string();
// i. If IsConstantDeclaration of d is true, then
if (is_constant_declaration) {
// 1. Perform ! env.CreateImmutableBinding(dn, true).
emit<Bytecode::Op::CreateImmutableBinding>(environment, intern_identifier(name), true);
}
// ii. Else,
else {
// 1. Perform ! env.CreateMutableBinding(dn, false). NOTE: This step is replaced in section B.3.2.6.
emit<Bytecode::Op::CreateMutableBinding>(environment, intern_identifier(name), false);
}
}));
// b. If d is either a FunctionDeclaration, a GeneratorDeclaration, an AsyncFunctionDeclaration, or an AsyncGeneratorDeclaration, then
if (is<FunctionDeclaration>(declaration)) {
// i. Let fn be the sole element of the BoundNames of d.
auto& function_declaration = static_cast<FunctionDeclaration const&>(declaration);
// ii. Let fo be InstantiateFunctionObject of d with arguments env and privateEnv.
LibJS: Pre-create SharedFunctionInstanceData in NewFunction Replace the FunctionNode const& stored on the NewFunction bytecode instruction with an index into a table of pre-created SharedFunctionInstanceData objects on the Executable. During bytecode compilation, we now eagerly create SharedFunctionInstanceData for each function that will be instantiated by NewFunction, and store it on both the FunctionNode (for caching) and the Executable (for GC tracing). At runtime, NewFunction simply looks up the SharedFunctionInstanceData by index and calls create_from_function_data() directly, bypassing the AST entirely. This removes one of the main reasons the AST had to stay alive after compilation. The instantiate_ordinary_function_expression() helper in Interpreter.cpp is removed as its non-trivial code path (creating a scope for named function expressions) was dead code -- it was only called when !has_name(), so the has_own_name branch never executed.
2026-02-10 23:02:46 +01:00
auto shared_data = ensure_shared_function_data(m_vm, function_declaration, function_declaration.name());
auto data_index = register_shared_function_data(shared_data);
LibJS: Generate bytecode for the BlockDeclarationInstantiation AO This necessitated adding some new instructions for creating mutable and immutable bindings.
2025-10-25 14:06:48 +02:00
auto fo = allocate_register();
LibJS: Pre-create SharedFunctionInstanceData in NewFunction Replace the FunctionNode const& stored on the NewFunction bytecode instruction with an index into a table of pre-created SharedFunctionInstanceData objects on the Executable. During bytecode compilation, we now eagerly create SharedFunctionInstanceData for each function that will be instantiated by NewFunction, and store it on both the FunctionNode (for caching) and the Executable (for GC tracing). At runtime, NewFunction simply looks up the SharedFunctionInstanceData by index and calls create_from_function_data() directly, bypassing the AST entirely. This removes one of the main reasons the AST had to stay alive after compilation. The instantiate_ordinary_function_expression() helper in Interpreter.cpp is removed as its non-trivial code path (creating a scope for named function expressions) was dead code -- it was only called when !has_name(), so the has_own_name branch never executed.
2026-02-10 23:02:46 +01:00
emit<Bytecode::Op::NewFunction>(fo, data_index, OptionalNone {}, OptionalNone {});
LibJS: Generate bytecode for the BlockDeclarationInstantiation AO This necessitated adding some new instructions for creating mutable and immutable bindings.
2025-10-25 14:06:48 +02:00
// iii. Perform ! env.InitializeBinding(fn, fo). NOTE: This step is replaced in section B.3.2.6.
if (function_declaration.name_identifier()->is_local()) {
auto local_index = function_declaration.name_identifier()->local_index();
if (local_index.is_variable()) {
emit<Bytecode::Op::Mov>(local(local_index), fo);
} else {
VERIFY_NOT_REACHED();
}
} else {
emit<Bytecode::Op::InitializeLexicalBinding>(intern_identifier(function_declaration.name()), fo);
}
}
}));
LibJS/Bytecode: Don't create empty lexical environments This patch stops emitting the BlockDeclarationInstantiation instruction when there are no locals, and no function declarations in the scope. We were spending 20% of CPU time on https://ventrella.com/Clusters/ just creating empty environments for no reason.
2024-05-11 13:25:08 +02:00
return true;
LibJS/Bytecode: Leave BlockDeclarationInstantiation in C++ Instead of implementing this AO in bytecode, we now have an instruction for it that simply invokes the C++ implementation. This allows us to simplify Bytecode::Generator quite a bit by removing all the variable scope tracking.
2023-06-16 16:34:47 +02:00
}
void Generator::begin_variable_scope()
{
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
auto parent_environment = m_lexical_environment_register_stack.last();
auto new_environment = allocate_register();
LibJS/Bytecode: Leave BlockDeclarationInstantiation in C++ Instead of implementing this AO in bytecode, we now have an instruction for it that simply invokes the C++ implementation. This allows us to simplify Bytecode::Generator quite a bit by removing all the variable scope tracking.
2023-06-16 16:34:47 +02:00
start_boundary(BlockBoundaryType::LeaveLexicalEnvironment);
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
emit<Bytecode::Op::CreateLexicalEnvironment>(new_environment, parent_environment, 0);
m_lexical_environment_register_stack.append(new_environment);
LibJS/Bytecode: Unwind environments before block terminating instruction When we reach a block terminating instruction (e.g. Break, Throw), we cannot generate anymore instructions after it. This would not allow us to leave any lexical/variable environments. This uses the mechanism introduced in ba9c49 to unwind environments when we encounter these instructions.
2022-03-14 02:34:01 +00:00
}
void Generator::end_variable_scope()
{
LibJS/Bytecode: Leave BlockDeclarationInstantiation in C++ Instead of implementing this AO in bytecode, we now have an instruction for it that simply invokes the C++ implementation. This allows us to simplify Bytecode::Generator quite a bit by removing all the variable scope tracking.
2023-06-16 16:34:47 +02:00
end_boundary(BlockBoundaryType::LeaveLexicalEnvironment);
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
m_lexical_environment_register_stack.take_last();
if (!m_current_basic_block->is_terminated())
emit<Bytecode::Op::SetLexicalEnvironment>(m_lexical_environment_register_stack.last());
}
LibJS/Bytecode: Unwind environments before block terminating instruction When we reach a block terminating instruction (e.g. Break, Throw), we cannot generate anymore instructions after it. This would not allow us to leave any lexical/variable environments. This uses the mechanism introduced in ba9c49 to unwind environments when we encounter these instructions.
2022-03-14 02:34:01 +00:00
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
void Generator::ensure_lexical_environment_register_initialized()
{
if (m_lexical_environment_register_stack.is_empty()) {
auto environment_register = ScopedOperand { *this, Operand { Register::saved_lexical_environment() } };
emit<Op::GetLexicalEnvironment>(environment_register);
m_lexical_environment_register_stack.append(environment_register);
LibJS/Bytecode: Unwind environments before block terminating instruction When we reach a block terminating instruction (e.g. Break, Throw), we cannot generate anymore instructions after it. This would not allow us to leave any lexical/variable environments. This uses the mechanism introduced in ba9c49 to unwind environments when we encounter these instructions.
2022-03-14 02:34:01 +00:00
}
}
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
ScopedOperand Generator::current_lexical_environment_register() const
{
VERIFY(!m_lexical_environment_register_stack.is_empty());
return m_lexical_environment_register_stack.last();
}
void Generator::push_lexical_environment_register(ScopedOperand const& environment)
{
m_lexical_environment_register_stack.append(environment);
}
void Generator::pop_lexical_environment_register()
{
m_lexical_environment_register_stack.take_last();
}
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
void Generator::begin_continuable_scope(Label continue_target, Vector<FlyString> const& language_label_set, Optional<ScopedOperand> completion_register)
LibJS: Add basic support for "continue" in the bytecode VM Unlike the convoluted unwind-until-scope-type mechanism in the AST interpreter, "continue" maps to a simple Bytecode::Op::Jump here. :^) We know where to jump based on a stack of "continuable scopes" that we now maintain on the Bytecode::Generator as we go. Note that this only supports bare "continue", not continue-with-label.
2021-06-06 13:33:02 +02:00
{
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
m_continuable_scopes.append({ continue_target, language_label_set, move(completion_register) });
LibJS: Leave the unwind context on break/continue/return in bytecode Otherwise we'd keep the old unwind context, and end up never invoking the other handlers up the stack.
2022-03-13 11:51:02 +03:30
start_boundary(BlockBoundaryType::Continue);
LibJS: Add basic support for "continue" in the bytecode VM Unlike the convoluted unwind-until-scope-type mechanism in the AST interpreter, "continue" maps to a simple Bytecode::Op::Jump here. :^) We know where to jump based on a stack of "continuable scopes" that we now maintain on the Bytecode::Generator as we go. Note that this only supports bare "continue", not continue-with-label.
2021-06-06 13:33:02 +02:00
}
void Generator::end_continuable_scope()
{
m_continuable_scopes.take_last();
LibJS: Leave the unwind context on break/continue/return in bytecode Otherwise we'd keep the old unwind context, and end up never invoking the other handlers up the stack.
2022-03-13 11:51:02 +03:30
end_boundary(BlockBoundaryType::Continue);
LibJS: Add basic support for "continue" in the bytecode VM Unlike the convoluted unwind-until-scope-type mechanism in the AST interpreter, "continue" maps to a simple Bytecode::Op::Jump here. :^) We know where to jump based on a stack of "continuable scopes" that we now maintain on the Bytecode::Generator as we go. Note that this only supports bare "continue", not continue-with-label.
2021-06-06 13:33:02 +02:00
}
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
LibJS: Implement bytecode generation for BreakStatement
2021-06-10 20:28:43 +08:00
Label Generator::nearest_breakable_scope() const
{
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
return m_breakable_scopes.last().bytecode_target;
LibJS: Implement bytecode generation for BreakStatement
2021-06-10 20:28:43 +08:00
}
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
void Generator::begin_breakable_scope(Label breakable_target, Vector<FlyString> const& language_label_set, Optional<ScopedOperand> completion_register)
LibJS: Implement bytecode generation for BreakStatement
2021-06-10 20:28:43 +08:00
{
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
m_breakable_scopes.append({ breakable_target, language_label_set, move(completion_register) });
LibJS: Leave the unwind context on break/continue/return in bytecode Otherwise we'd keep the old unwind context, and end up never invoking the other handlers up the stack.
2022-03-13 11:51:02 +03:30
start_boundary(BlockBoundaryType::Break);
LibJS: Implement bytecode generation for BreakStatement
2021-06-10 20:28:43 +08:00
}
LibJS: Add basic support for "continue" in the bytecode VM Unlike the convoluted unwind-until-scope-type mechanism in the AST interpreter, "continue" maps to a simple Bytecode::Op::Jump here. :^) We know where to jump based on a stack of "continuable scopes" that we now maintain on the Bytecode::Generator as we go. Note that this only supports bare "continue", not continue-with-label.
2021-06-06 13:33:02 +02:00
LibJS: Implement bytecode generation for BreakStatement
2021-06-10 20:28:43 +08:00
void Generator::end_breakable_scope()
{
m_breakable_scopes.take_last();
LibJS: Leave the unwind context on break/continue/return in bytecode Otherwise we'd keep the old unwind context, and end up never invoking the other handlers up the stack.
2022-03-13 11:51:02 +03:30
end_boundary(BlockBoundaryType::Break);
LibJS: Implement bytecode generation for BreakStatement
2021-06-10 20:28:43 +08:00
}
LibJS: Add BytecodeGenerator helpers for reference get/put This allows code sharing between all AST nodes that want to get and/or put through a reference.
2021-10-25 15:16:22 +02:00
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Generator::ReferenceOperands Generator::emit_super_reference(MemberExpression const& expression)
LibJS/Bytecode: Extract code to generate a super reference to a helper This code is already repeated twice, and would be repeated a third time for the `delete` operator.
2023-07-06 17:02:06 -04:00
{
VERIFY(is<SuperExpression>(expression.object()));
// https://tc39.es/ecma262/#sec-super-keyword-runtime-semantics-evaluation
// 1. Let env be GetThisEnvironment().
// 2. Let actualThis be ? env.GetThisBinding().
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
auto actual_this = get_this();
LibJS/Bytecode: Extract code to generate a super reference to a helper This code is already repeated twice, and would be repeated a third time for the `delete` operator.
2023-07-06 17:02:06 -04:00
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
Optional<ScopedOperand> computed_property_value;
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
Optional<PropertyKeyTableIndex> property_key_id;
LibJS/Bytecode: Extract code to generate a super reference to a helper This code is already repeated twice, and would be repeated a third time for the `delete` operator.
2023-07-06 17:02:06 -04:00
if (expression.is_computed()) {
// SuperProperty : super [ Expression ]
// 3. Let propertyNameReference be ? Evaluation of Expression.
// 4. Let propertyNameValue be ? GetValue(propertyNameReference).
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
computed_property_value = expression.property().generate_bytecode(*this).value();
LibJS: Fix bytecode generation for super property stores and loads The new test case crashes during bytecode generation due to `emit_super_reference` not correctly generating the reference record for the property access.
2025-02-13 22:10:58 +13:00
} else {
// SuperProperty : super . IdentifierName
// 3. Let propertyKey be the StringValue of IdentifierName.
auto const identifier_name = as<Identifier>(expression.property()).string();
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
property_key_id = intern_property_key(identifier_name);
LibJS/Bytecode: Extract code to generate a super reference to a helper This code is already repeated twice, and would be repeated a third time for the `delete` operator.
2023-07-06 17:02:06 -04:00
}
// 5/7. Return ? MakeSuperPropertyReference(actualThis, propertyKey, strict).
// https://tc39.es/ecma262/#sec-makesuperpropertyreference
// 1. Let env be GetThisEnvironment().
// 2. Assert: env.HasSuperBinding() is true.
// 3. Let baseValue be ? env.GetSuperBase().
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto base_value = allocate_register();
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
emit<Bytecode::Op::ResolveSuperBase>(base_value);
LibJS/Bytecode: Extract code to generate a super reference to a helper This code is already repeated twice, and would be repeated a third time for the `delete` operator.
2023-07-06 17:02:06 -04:00
// 4. Return the Reference Record { [[Base]]: baseValue, [[ReferencedName]]: propertyKey, [[Strict]]: strict, [[ThisValue]]: actualThis }.
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 ReferenceOperands {
.base = base_value,
.referenced_name = computed_property_value,
LibJS: Fix bytecode generation for super property stores and loads The new test case crashes during bytecode generation due to `emit_super_reference` not correctly generating the reference record for the property access.
2025-02-13 22:10:58 +13:00
.referenced_identifier = property_key_id,
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
.this_value = actual_this,
LibJS/Bytecode: Extract code to generate a super reference to a helper This code is already repeated twice, and would be repeated a third time for the `delete` operator.
2023-07-06 17:02:06 -04:00
};
}
LibJS: Skip unnecessary Mov in emit_load_from_reference for reads When MemberExpression::generate_bytecode calls emit_load_from_reference, it only uses the loaded_value and discards the reference operands. For computed member expressions (e.g. a[0]), this was generating an unnecessary Mov to save the property register for potential store-back. Add a ReferenceMode parameter to emit_load_from_reference. When LoadOnly is passed, the computed property path skips the register save and Mov.
2026-02-15 12:16:19 +01:00
Generator::ReferenceOperands Generator::emit_load_from_reference(JS::ASTNode const& node, Optional<ScopedOperand> preferred_dst, ReferenceMode mode)
LibJS: Add BytecodeGenerator helpers for reference get/put This allows code sharing between all AST nodes that want to get and/or put through a reference.
2021-10-25 15:16:22 +02:00
{
if (is<Identifier>(node)) {
auto& identifier = static_cast<Identifier const&>(node);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto loaded_value = identifier.generate_bytecode(*this, preferred_dst).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 ReferenceOperands {
.loaded_value = loaded_value,
};
LibJS: Add BytecodeGenerator helpers for reference get/put This allows code sharing between all AST nodes that want to get and/or put through a reference.
2021-10-25 15:16:22 +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 (!is<MemberExpression>(node)) {
LibJS: Throw ReferenceError for invalid assignment targets like foo()=x CallExpression is accepted as an assignment target for web compatibility (Annex B), but must throw ReferenceError at runtime. We were incorrectly throwing TypeError with a TODO message. Replace emit_todo() calls in three codegen paths (simple assignment, compound assignment/update, and for-in/of) with proper ReferenceError using the "Invalid left-hand side in assignment" message, matching the behavior of V8 and JSC.
2026-02-11 23:22:50 +01:00
// Per spec, evaluate the expression (e.g. the call in f()++) before
// throwing ReferenceError for invalid assignment target.
(void)node.generate_bytecode(*this);
auto exception = allocate_register();
emit<Bytecode::Op::NewReferenceError>(exception, intern_string(ErrorType::InvalidLeftHandAssignment.message()));
perform_needed_unwinds<Op::Throw>();
emit<Bytecode::Op::Throw>(exception);
switch_to_basic_block(make_block());
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto dummy = add_constant(js_undefined());
return ReferenceOperands {
.base = dummy,
.referenced_name = dummy,
.this_value = dummy,
.loaded_value = dummy,
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& expression = static_cast<MemberExpression const&>(node);
LibJS: Don't evaluate computed MemberExpression LHS twice in assignments The following snippet would cause "i" to be incremented twice(!): let a = [] let i = 0 a[++i] += 0 This patch solves the issue by remembering the base object and property name for computed MemberExpression LHS in codegen. We the store the result of the assignment to the same object and property (instead of computing the LHS again). 3 new passes on test262. :^)
2023-10-04 15:22:07 +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
// https://tc39.es/ecma262/#sec-super-keyword-runtime-semantics-evaluation
if (is<SuperExpression>(expression.object())) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto super_reference = emit_super_reference(expression);
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto dst = preferred_dst.has_value() ? preferred_dst.value() : allocate_register();
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 (super_reference.referenced_name.has_value()) {
// 5. Let propertyKey be ? ToPropertyKey(propertyNameValue).
LibJS: Emit GetById instead of GetByValue when key is string literal Basically convert o["foo"] into o.foo when emitting bytecode. These are effectively the same thing, and the latter format opts into using an inline cache for the property lookups.
2025-04-03 14:18:24 +02:00
emit_get_by_value_with_this(dst, *super_reference.base, *super_reference.referenced_name, *super_reference.this_value);
LibJS: Make ASTNode::generate_bytecode() fallible Instead of crashing on the spot, return a descriptive error that will eventually continue its days as a javascript "InternalError" exception. This should make random crashes with BC less likely.
2022-02-12 19:54:08 +03:30
} else {
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
// 3. Let propertyKey be StringValue of IdentifierName.
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
auto property_key_table_index = intern_property_key(as<Identifier>(expression.property()).string());
emit_get_by_id_with_this(dst, *super_reference.base, property_key_table_index, *super_reference.this_value);
LibJS: Add BytecodeGenerator helpers for reference get/put This allows code sharing between all AST nodes that want to get and/or put through a reference.
2021-10-25 15:16:22 +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
super_reference.loaded_value = dst;
return super_reference;
}
LibJS: Include identifier information in nullish property read access When a GetById / GetByValue bytecode operation results in accessing a nullish object, we now include the name of the property and the object being accessed in the exception message (if available). This should make it easier to debug live websites. For example, the following errors would all previously produce a generic error message of "ToObject on null or undefined": > foo = null > foo.bar Uncaught exception: [TypeError] Cannot access property "bar" on null object "foo" at <unknown> > foo = { bar: undefined } > foo.bar.baz Uncaught exception: [TypeError] Cannot access property "baz" on undefined object "foo.bar" at <unknown> Note we certainly don't capture all possible nullish property read accesses here. This just covers cases I've seen most on live websites; we can cover more cases as they arise.
2024-03-29 11:26:10 -04:00
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto base = expression.object().generate_bytecode(*this).value();
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
auto base_identifier = intern_identifier_for_expression(expression.object());
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 (expression.is_computed()) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto property = expression.property().generate_bytecode(*this).value();
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto dst = preferred_dst.has_value() ? preferred_dst.value() : allocate_register();
LibJS: Emit GetById instead of GetByValue when key is string literal Basically convert o["foo"] into o.foo when emitting bytecode. These are effectively the same thing, and the latter format opts into using an inline cache for the property lookups.
2025-04-03 14:18:24 +02:00
emit_get_by_value(dst, base, property, move(base_identifier));
LibJS: Skip unnecessary Mov in emit_load_from_reference for reads When MemberExpression::generate_bytecode calls emit_load_from_reference, it only uses the loaded_value and discards the reference operands. For computed member expressions (e.g. a[0]), this was generating an unnecessary Mov to save the property register for potential store-back. Add a ReferenceMode parameter to emit_load_from_reference. When LoadOnly is passed, the computed property path skips the register save and Mov.
2026-02-15 12:16:19 +01:00
if (mode == ReferenceMode::LoadOnly) {
return ReferenceOperands {
.loaded_value = dst,
};
}
auto saved_property = allocate_register();
emit<Bytecode::Op::Mov>(saved_property, property);
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 ReferenceOperands {
.base = base,
LibJS/Bytecode: Always evaluate LHS first in assignment expressions This fixes an issue where expressions like `a[i] = a[++i]` could evaluate `++i` before `a[i]`.
2024-03-05 09:48:13 +01:00
.referenced_name = saved_property,
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
.this_value = base,
.loaded_value = dst,
};
}
if (expression.property().is_identifier()) {
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
auto property_key_table_index = intern_property_key(as<Identifier>(expression.property()).string());
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto dst = preferred_dst.has_value() ? preferred_dst.value() : allocate_register();
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
emit_get_by_id(dst, base, property_key_table_index, move(base_identifier));
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 ReferenceOperands {
.base = base,
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
.referenced_identifier = property_key_table_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
.this_value = base,
.loaded_value = dst,
};
}
if (expression.property().is_private_identifier()) {
AK+Everywhere: Rename `verify_cast` to `as` Follow-up to fc20e61e7249006247b43f84a3189d5a37fa103e.
2025-01-21 09:12:05 -05:00
auto identifier_table_ref = intern_identifier(as<PrivateIdentifier>(expression.property()).string());
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto dst = preferred_dst.has_value() ? preferred_dst.value() : allocate_register();
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
emit<Bytecode::Op::GetPrivateById>(dst, base, identifier_table_ref);
return ReferenceOperands {
.base = base,
.referenced_private_identifier = identifier_table_ref,
.this_value = base,
.loaded_value = dst,
};
LibJS: Add BytecodeGenerator helpers for reference get/put This allows code sharing between all AST nodes that want to get and/or put through a reference.
2021-10-25 15:16:22 +02:00
}
LibJS: Convert unreachable codegen error sites to VERIFY Replace CodeGenerationError returns with VERIFY_NOT_REACHED() or VERIFY() at sites that are provably unreachable: - Non-computed member expression fallbacks in emit_load_from_reference, emit_store_to_reference, and emit_delete_reference (member expression properties are always computed, identifier, or private identifier) - Two non-computed member expression fallbacks in AssignmentExpression - Default case in compound assignment switch (all 15 AssignmentOp values are handled) - BindingPattern Empty/Expression name+alias pair (computed property names always require an alias) - Two assignment+destructuring combinations in for-in/of body evaluation (is_destructuring is only set for VariableDeclaration lhs, which always has VarBinding or LexicalBinding kind, never Assignment)
2026-02-11 22:05:55 +01:00
VERIFY_NOT_REACHED();
LibJS: Add BytecodeGenerator helpers for reference get/put This allows code sharing between all AST nodes that want to get and/or put through a reference.
2021-10-25 15:16:22 +02:00
}
LibJS: Fix evaluation order in array destructuring assignment Per AssignmentRestElement and AssignmentElement in the specification, the DestructuringAssignmentTarget reference must be evaluated before iterating or stepping the iterator. We were doing it in the wrong order, which caused observable differences when the target evaluation has side effects, and could lead to infinite loops when the iterator never completes. Add Generator::emit_evaluate_reference() to evaluate a member expression's base and property into ReferenceOperands without performing a load or store, then use the pre-evaluated reference for the store after iteration completes.
2026-02-15 12:24:34 +01:00
Generator::ReferenceOperands Generator::emit_evaluate_reference(MemberExpression const& expression)
{
// https://tc39.es/ecma262/#sec-super-keyword-runtime-semantics-evaluation
if (is<SuperExpression>(expression.object())) {
return emit_super_reference(expression);
}
auto base = expression.object().generate_bytecode(*this).value();
if (expression.is_computed()) {
auto property = expression.property().generate_bytecode(*this).value();
auto saved_property = allocate_register();
emit<Bytecode::Op::Mov>(saved_property, property);
return ReferenceOperands {
.base = base,
.referenced_name = saved_property,
.this_value = base,
};
}
if (expression.property().is_identifier()) {
auto property_key_table_index = intern_property_key(as<Identifier>(expression.property()).string());
return ReferenceOperands {
.base = base,
.referenced_identifier = property_key_table_index,
.this_value = base,
};
}
if (expression.property().is_private_identifier()) {
auto identifier_table_ref = intern_identifier(as<PrivateIdentifier>(expression.property()).string());
return ReferenceOperands {
.base = base,
.referenced_private_identifier = identifier_table_ref,
.this_value = base,
};
}
VERIFY_NOT_REACHED();
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
void Generator::emit_store_to_reference(JS::ASTNode const& node, ScopedOperand value)
LibJS: Add BytecodeGenerator helpers for reference get/put This allows code sharing between all AST nodes that want to get and/or put through a reference.
2021-10-25 15:16:22 +02:00
{
if (is<Identifier>(node)) {
auto& identifier = static_cast<Identifier const&>(node);
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
emit_set_variable(identifier, value);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return;
LibJS: Add BytecodeGenerator helpers for reference get/put This allows code sharing between all AST nodes that want to get and/or put through a reference.
2021-10-25 15:16:22 +02:00
}
if (is<MemberExpression>(node)) {
auto& expression = static_cast<MemberExpression const&>(node);
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
// https://tc39.es/ecma262/#sec-super-keyword-runtime-semantics-evaluation
if (is<SuperExpression>(expression.object())) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto super_reference = emit_super_reference(expression);
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
// 4. Return the Reference Record { [[Base]]: baseValue, [[ReferencedName]]: propertyKey, [[Strict]]: strict, [[ThisValue]]: actualThis }.
LibJS/Bytecode: Extract code to generate a super reference to a helper This code is already repeated twice, and would be repeated a third time for the `delete` operator.
2023-07-06 17:02:06 -04:00
if (super_reference.referenced_name.has_value()) {
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
// 5. Let propertyKey be ? ToPropertyKey(propertyNameValue).
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
emit_put_by_value_with_this(*super_reference.base, *super_reference.referenced_name, *super_reference.this_value, value, PutKind::Normal);
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
} else {
// 3. Let propertyKey be StringValue of IdentifierName.
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
auto property_key_table_index = intern_property_key(as<Identifier>(expression.property()).string());
emit<Bytecode::Op::PutNormalByIdWithThis>(*super_reference.base, *super_reference.this_value, property_key_table_index, value, next_property_lookup_cache());
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
}
LibJS: Make ASTNode::generate_bytecode() fallible Instead of crashing on the spot, return a descriptive error that will eventually continue its days as a javascript "InternalError" exception. This should make random crashes with BC less likely.
2022-02-12 19:54:08 +03:30
} else {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto object = expression.object().generate_bytecode(*this).value();
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
if (expression.is_computed()) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto property = expression.property().generate_bytecode(*this).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
emit_put_by_value(object, property, value, PutKind::Normal, {});
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
} else if (expression.property().is_identifier()) {
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
auto property_key_table_index = intern_property_key(as<Identifier>(expression.property()).string());
emit_put_by_id(object, property_key_table_index, value, Bytecode::PutKind::Normal, next_property_lookup_cache());
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
} else if (expression.property().is_private_identifier()) {
AK+Everywhere: Rename `verify_cast` to `as` Follow-up to fc20e61e7249006247b43f84a3189d5a37fa103e.
2025-01-21 09:12:05 -05:00
auto identifier_table_ref = intern_identifier(as<PrivateIdentifier>(expression.property()).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
emit<Bytecode::Op::PutPrivateById>(object, identifier_table_ref, value);
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
} else {
LibJS: Convert unreachable codegen error sites to VERIFY Replace CodeGenerationError returns with VERIFY_NOT_REACHED() or VERIFY() at sites that are provably unreachable: - Non-computed member expression fallbacks in emit_load_from_reference, emit_store_to_reference, and emit_delete_reference (member expression properties are always computed, identifier, or private identifier) - Two non-computed member expression fallbacks in AssignmentExpression - Default case in compound assignment switch (all 15 AssignmentOp values are handled) - BindingPattern Empty/Expression name+alias pair (computed property names always require an alias) - Two assignment+destructuring combinations in for-in/of body evaluation (is_destructuring is only set for VariableDeclaration lhs, which always has VarBinding or LexicalBinding kind, never Assignment)
2026-02-11 22:05:55 +01:00
VERIFY_NOT_REACHED();
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
}
LibJS: Add BytecodeGenerator helpers for reference get/put This allows code sharing between all AST nodes that want to get and/or put through a reference.
2021-10-25 15:16:22 +02:00
}
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return;
LibJS: Add BytecodeGenerator helpers for reference get/put This allows code sharing between all AST nodes that want to get and/or put through a reference.
2021-10-25 15:16:22 +02:00
}
LibJS: Make ASTNode::generate_bytecode() fallible Instead of crashing on the spot, return a descriptive error that will eventually continue its days as a javascript "InternalError" exception. This should make random crashes with BC less likely.
2022-02-12 19:54:08 +03:30
LibJS: Throw ReferenceError for invalid assignment targets like foo()=x CallExpression is accepted as an assignment target for web compatibility (Annex B), but must throw ReferenceError at runtime. We were incorrectly throwing TypeError with a TODO message. Replace emit_todo() calls in three codegen paths (simple assignment, compound assignment/update, and for-in/of) with proper ReferenceError using the "Invalid left-hand side in assignment" message, matching the behavior of V8 and JSC.
2026-02-11 23:22:50 +01:00
// Per spec, evaluate the expression (e.g. the call in for(f() in ...))
// before throwing ReferenceError for invalid assignment target.
(void)node.generate_bytecode(*this);
auto exception = allocate_register();
emit<Bytecode::Op::NewReferenceError>(exception, intern_string(ErrorType::InvalidLeftHandAssignment.message()));
perform_needed_unwinds<Op::Throw>();
emit<Bytecode::Op::Throw>(exception);
switch_to_basic_block(make_block());
LibJS: Add BytecodeGenerator helpers for reference get/put This allows code sharing between all AST nodes that want to get and/or put through a reference.
2021-10-25 15:16:22 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
void Generator::emit_store_to_reference(ReferenceOperands const& reference, ScopedOperand value)
LibJS: Don't evaluate computed MemberExpression LHS twice in assignments The following snippet would cause "i" to be incremented twice(!): let a = [] let i = 0 a[++i] += 0 This patch solves the issue by remembering the base object and property name for computed MemberExpression LHS in codegen. We the store the result of the assignment to the same object and property (instead of computing the LHS again). 3 new passes on test262. :^)
2023-10-04 15:22:07 +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 (reference.referenced_private_identifier.has_value()) {
emit<Bytecode::Op::PutPrivateById>(*reference.base, *reference.referenced_private_identifier, value);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return;
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 (reference.referenced_identifier.has_value()) {
if (reference.base == reference.this_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
emit_put_by_id(*reference.base, *reference.referenced_identifier, value, Bytecode::PutKind::Normal, next_property_lookup_cache());
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
LibJS: Split PutBy* instructions into specialized per-kind variants This allows the compiler to fold away lots of unused code for each kind. 1.10x speed-up on MicroBench/pic-add-own.js :^)
2025-10-10 12:09:34 +02:00
emit<Bytecode::Op::PutNormalByIdWithThis>(*reference.base, *reference.this_value, *reference.referenced_identifier, value, next_property_lookup_cache());
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return;
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 (reference.base == reference.this_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
emit_put_by_value(*reference.base, *reference.referenced_name, value, PutKind::Normal, {});
LibJS: Don't evaluate computed MemberExpression LHS twice in assignments The following snippet would cause "i" to be incremented twice(!): let a = [] let i = 0 a[++i] += 0 This patch solves the issue by remembering the base object and property name for computed MemberExpression LHS in codegen. We the store the result of the assignment to the same object and property (instead of computing the LHS again). 3 new passes on test262. :^)
2023-10-04 15:22:07 +02:00
else
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
emit_put_by_value_with_this(*reference.base, *reference.referenced_name, *reference.this_value, value, PutKind::Normal);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return;
LibJS: Don't evaluate computed MemberExpression LHS twice in assignments The following snippet would cause "i" to be incremented twice(!): let a = [] let i = 0 a[++i] += 0 This patch solves the issue by remembering the base object and property name for computed MemberExpression LHS in codegen. We the store the result of the assignment to the same object and property (instead of computing the LHS again). 3 new passes on test262. :^)
2023-10-04 15:22:07 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> Generator::emit_delete_reference(JS::ASTNode const& node)
LibJS/Bytecode: Implement the delete unary expression `delete` has to operate directly on Reference Records, so this introduces a new set of operations called DeleteByValue, DeleteVariable and DeleteById. They operate similarly to their Get counterparts, except they end in creating a (temporary) Reference and calling delete_ on it.
2022-03-27 19:50:09 +01:00
{
if (is<Identifier>(node)) {
auto& identifier = static_cast<Identifier const&>(node);
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 (identifier.is_local()) {
return add_constant(Value(false));
}
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto dst = allocate_register();
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
emit<Bytecode::Op::DeleteVariable>(dst, intern_identifier(identifier.string()));
return dst;
LibJS/Bytecode: Implement the delete unary expression `delete` has to operate directly on Reference Records, so this introduces a new set of operations called DeleteByValue, DeleteVariable and DeleteById. They operate similarly to their Get counterparts, except they end in creating a (temporary) Reference and calling delete_ on it.
2022-03-27 19:50:09 +01:00
}
if (is<MemberExpression>(node)) {
auto& expression = static_cast<MemberExpression const&>(node);
LibJS/Bytecode: Generate bytecode for deleting super properties
2023-07-06 17:10:40 -04:00
// https://tc39.es/ecma262/#sec-super-keyword-runtime-semantics-evaluation
if (is<SuperExpression>(expression.object())) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto super_reference = emit_super_reference(expression);
LibJS/Bytecode: Generate bytecode for deleting super properties
2023-07-06 17:10:40 -04:00
LibJS: Throw ReferenceError for delete super[...] at codegen time delete super.x and delete super[expr] always throw a ReferenceError per spec. Instead of deferring this to runtime via DeleteByIdWithThis and DeleteByValueWithThis instructions, emit the throw directly during bytecode generation. Remove the now-unused DeleteByIdWithThis and DeleteByValueWithThis instructions, and add a NewReferenceError instruction.
2026-02-11 13:14:52 +01:00
auto exception = allocate_register();
emit<Bytecode::Op::NewReferenceError>(exception, intern_string(ErrorType::UnsupportedDeleteSuperProperty.message()));
perform_needed_unwinds<Op::Throw>();
emit<Bytecode::Op::Throw>(exception);
// Switch to a new block so callers can continue emitting code
// (which will be unreachable, but avoids a terminated-block VERIFY).
switch_to_basic_block(make_block());
return add_constant(js_undefined());
LibJS/Bytecode: Generate bytecode for deleting super properties
2023-07-06 17:10:40 -04:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto object = expression.object().generate_bytecode(*this).value();
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto dst = allocate_register();
LibJS/Bytecode: Implement the delete unary expression `delete` has to operate directly on Reference Records, so this introduces a new set of operations called DeleteByValue, DeleteVariable and DeleteById. They operate similarly to their Get counterparts, except they end in creating a (temporary) Reference and calling delete_ on it.
2022-03-27 19:50:09 +01:00
if (expression.is_computed()) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto property = expression.property().generate_bytecode(*this).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
emit<Bytecode::Op::DeleteByValue>(dst, object, property);
LibJS/Bytecode: Implement the delete unary expression `delete` has to operate directly on Reference Records, so this introduces a new set of operations called DeleteByValue, DeleteVariable and DeleteById. They operate similarly to their Get counterparts, except they end in creating a (temporary) Reference and calling delete_ on it.
2022-03-27 19:50:09 +01:00
} else if (expression.property().is_identifier()) {
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
auto property_key_table_index = intern_property_key(as<Identifier>(expression.property()).string());
emit<Bytecode::Op::DeleteById>(dst, object, property_key_table_index);
LibJS/Bytecode: Implement the delete unary expression `delete` has to operate directly on Reference Records, so this introduces a new set of operations called DeleteByValue, DeleteVariable and DeleteById. They operate similarly to their Get counterparts, except they end in creating a (temporary) Reference and calling delete_ on it.
2022-03-27 19:50:09 +01:00
} else {
LibJS: Convert unreachable codegen error sites to VERIFY Replace CodeGenerationError returns with VERIFY_NOT_REACHED() or VERIFY() at sites that are provably unreachable: - Non-computed member expression fallbacks in emit_load_from_reference, emit_store_to_reference, and emit_delete_reference (member expression properties are always computed, identifier, or private identifier) - Two non-computed member expression fallbacks in AssignmentExpression - Default case in compound assignment switch (all 15 AssignmentOp values are handled) - BindingPattern Empty/Expression name+alias pair (computed property names always require an alias) - Two assignment+destructuring combinations in for-in/of body evaluation (is_destructuring is only set for VariableDeclaration lhs, which always has VarBinding or LexicalBinding kind, never Assignment)
2026-02-11 22:05:55 +01:00
// NB: Trying to delete a private field generates a SyntaxError in the parser.
VERIFY_NOT_REACHED();
LibJS/Bytecode: Implement the delete unary expression `delete` has to operate directly on Reference Records, so this introduces a new set of operations called DeleteByValue, DeleteVariable and DeleteById. They operate similarly to their Get counterparts, except they end in creating a (temporary) Reference and calling delete_ on it.
2022-03-27 19:50:09 +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 dst;
LibJS/Bytecode: Implement the delete unary expression `delete` has to operate directly on Reference Records, so this introduces a new set of operations called DeleteByValue, DeleteVariable and DeleteById. They operate similarly to their Get counterparts, except they end in creating a (temporary) Reference and calling delete_ on it.
2022-03-27 19:50:09 +01:00
}
// Though this will have no deletion effect, we still have to evaluate the node as it can have side effects.
// For example: delete a(); delete ++c.b; etc.
// 13.5.1.2 Runtime Semantics: Evaluation, https://tc39.es/ecma262/#sec-delete-operator-runtime-semantics-evaluation
// 1. Let ref be the result of evaluating UnaryExpression.
// 2. ReturnIfAbrupt(ref).
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
(void)node.generate_bytecode(*this);
LibJS/Bytecode: Implement the delete unary expression `delete` has to operate directly on Reference Records, so this introduces a new set of operations called DeleteByValue, DeleteVariable and DeleteById. They operate similarly to their Get counterparts, except they end in creating a (temporary) Reference and calling delete_ on it.
2022-03-27 19:50:09 +01:00
// 3. If ref is not a Reference Record, return true.
// NOTE: The rest of the steps are handled by Delete{Variable,ByValue,Id}.
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 add_constant(Value(true));
LibJS/Bytecode: Implement the delete unary expression `delete` has to operate directly on Reference Records, so this introduces a new set of operations called DeleteByValue, DeleteVariable and DeleteById. They operate similarly to their Get counterparts, except they end in creating a (temporary) Reference and calling delete_ on it.
2022-03-27 19:50:09 +01: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
void Generator::emit_set_variable(JS::Identifier const& identifier, ScopedOperand value, Bytecode::Op::BindingInitializationMode initialization_mode, Bytecode::Op::EnvironmentMode environment_mode)
LibJS: Update bytecode generator to use local variables - Update ECMAScriptFunctionObject::function_declaration_instantiation to initialize local variables - Introduce GetLocal, SetLocal, TypeofLocal that will be used to operate on local variables. - Update bytecode generator to emit instructions for local variables
2023-07-05 02:17:10 +02:00
{
if (identifier.is_local()) {
LibJS: Do not allow reassignment to local const variable
2026-02-09 20:27:31 +01:00
if (initialization_mode == Bytecode::Op::BindingInitializationMode::Set && identifier.declaration_kind() == DeclarationKind::Const) {
emit<Bytecode::Op::ThrowConstAssignment>();
return;
}
LibJS: Skip allocating locals for arguments that allowed to be local This allows us to get rid of instructions that move arguments to locals and allocate smaller JS::Value vector in ExecutionContext by reusing slots that were already allocated for arguments. With this change for following function: ```js function f(x, y) { return x + y; } ``` we now produce following bytecode: ``` [ 0] 0: Add dst:reg6, lhs:arg0, rhs:arg1 [ 10] Return value:reg6 ``` instead of: ``` [ 0] 0: GetArgument 0, dst:x~1 [ 10] GetArgument 1, dst:y~0 [ 20] Add dst:reg6, lhs:x~1, rhs:y~0 [ 30] Return value:reg6 ```
2025-04-25 17:10:47 +02:00
auto local_index = identifier.local_index();
if (value.operand().is_local() && local_index.is_variable() && value.operand().index() == local_index.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
// Moving a local to itself is a no-op.
return;
}
LibJS: Skip allocating locals for arguments that allowed to be local This allows us to get rid of instructions that move arguments to locals and allocate smaller JS::Value vector in ExecutionContext by reusing slots that were already allocated for arguments. With this change for following function: ```js function f(x, y) { return x + y; } ``` we now produce following bytecode: ``` [ 0] 0: Add dst:reg6, lhs:arg0, rhs:arg1 [ 10] Return value:reg6 ``` instead of: ``` [ 0] 0: GetArgument 0, dst:x~1 [ 10] GetArgument 1, dst:y~0 [ 20] Add dst:reg6, lhs:x~1, rhs:y~0 [ 30] Return value:reg6 ```
2025-04-25 17:10:47 +02:00
emit<Bytecode::Op::Mov>(local(local_index), value);
LibJS: Update bytecode generator to use local variables - Update ECMAScriptFunctionObject::function_declaration_instantiation to initialize local variables - Introduce GetLocal, SetLocal, TypeofLocal that will be used to operate on local variables. - Update bytecode generator to emit instructions for local variables
2023-07-05 02:17:10 +02:00
} else {
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 identifier_index = intern_identifier(identifier.string());
if (environment_mode == Bytecode::Op::EnvironmentMode::Lexical) {
if (initialization_mode == Bytecode::Op::BindingInitializationMode::Initialize) {
emit<Bytecode::Op::InitializeLexicalBinding>(identifier_index, value);
} else if (initialization_mode == Bytecode::Op::BindingInitializationMode::Set) {
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 (identifier.is_global()) {
emit<Bytecode::Op::SetGlobal>(identifier_index, value, next_global_variable_cache());
} else {
emit<Bytecode::Op::SetLexicalBinding>(identifier_index, value);
}
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
}
} else if (environment_mode == Bytecode::Op::EnvironmentMode::Var) {
if (initialization_mode == Bytecode::Op::BindingInitializationMode::Initialize) {
emit<Bytecode::Op::InitializeVariableBinding>(identifier_index, value);
} else if (initialization_mode == Bytecode::Op::BindingInitializationMode::Set) {
emit<Bytecode::Op::SetVariableBinding>(identifier_index, value);
}
} else {
VERIFY_NOT_REACHED();
}
LibJS: Update bytecode generator to use local variables - Update ECMAScriptFunctionObject::function_declaration_instantiation to initialize local variables - Introduce GetLocal, SetLocal, TypeofLocal that will be used to operate on local variables. - Update bytecode generator to emit instructions for local variables
2023-07-05 02:17:10 +02:00
}
}
LibJS: Port remaining bytecode identifiers to UTF-16
2025-08-07 16:34:36 -04:00
static Optional<Utf16String> expression_identifier(Expression const& expression)
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
{
if (expression.is_identifier()) {
auto const& identifier = static_cast<Identifier const&>(expression);
LibJS: Port remaining bytecode identifiers to UTF-16
2025-08-07 16:34:36 -04:00
return identifier.string().to_utf16_string();
LibJS: Include identifier information in nullish property read access When a GetById / GetByValue bytecode operation results in accessing a nullish object, we now include the name of the property and the object being accessed in the exception message (if available). This should make it easier to debug live websites. For example, the following errors would all previously produce a generic error message of "ToObject on null or undefined": > foo = null > foo.bar Uncaught exception: [TypeError] Cannot access property "bar" on null object "foo" at <unknown> > foo = { bar: undefined } > foo.bar.baz Uncaught exception: [TypeError] Cannot access property "baz" on undefined object "foo.bar" at <unknown> Note we certainly don't capture all possible nullish property read accesses here. This just covers cases I've seen most on live websites; we can cover more cases as they arise.
2024-03-29 11:26:10 -04:00
}
LibJS: Support numeric literal expressions in nullish object exceptions
2024-04-01 22:02:03 -04:00
if (expression.is_numeric_literal()) {
auto const& literal = static_cast<NumericLiteral const&>(expression);
LibJS: Port remaining bytecode identifiers to UTF-16
2025-08-07 16:34:36 -04:00
return literal.value().to_utf16_string_without_side_effects();
LibJS: Support numeric literal expressions in nullish object exceptions
2024-04-01 22:02:03 -04:00
}
LibJS: Support string literal expressions in nullish object exceptions
2024-04-01 22:06:03 -04:00
if (expression.is_string_literal()) {
auto const& literal = static_cast<StringLiteral const&>(expression);
LibJS: Port remaining bytecode identifiers to UTF-16
2025-08-07 16:34:36 -04:00
return Utf16String::formatted("'{}'", literal.value());
LibJS: Support string literal expressions in nullish object exceptions
2024-04-01 22:06:03 -04:00
}
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
if (expression.is_member_expression()) {
auto const& member_expression = static_cast<MemberExpression const&>(expression);
LibJS: Port remaining bytecode identifiers to UTF-16
2025-08-07 16:34:36 -04:00
StringBuilder builder(StringBuilder::Mode::UTF16);
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
LibWeb+LibJS+Tests: Fix typos - act I
2025-03-08 14:20:48 +00:00
if (auto identifier = expression_identifier(member_expression.object()); identifier.has_value())
builder.append(*identifier);
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
LibWeb+LibJS+Tests: Fix typos - act I
2025-03-08 14:20:48 +00:00
if (auto identifier = expression_identifier(member_expression.property()); identifier.has_value()) {
LibJS: Support computed member expressions in nullish object exceptions
2024-04-01 22:00:29 -04:00
if (member_expression.is_computed())
LibWeb+LibJS+Tests: Fix typos - act I
2025-03-08 14:20:48 +00:00
builder.appendff("[{}]", *identifier);
LibJS: Support computed member expressions in nullish object exceptions
2024-04-01 22:00:29 -04:00
else
LibWeb+LibJS+Tests: Fix typos - act I
2025-03-08 14:20:48 +00:00
builder.appendff(".{}", *identifier);
LibJS: Include identifier information in nullish property read access When a GetById / GetByValue bytecode operation results in accessing a nullish object, we now include the name of the property and the object being accessed in the exception message (if available). This should make it easier to debug live websites. For example, the following errors would all previously produce a generic error message of "ToObject on null or undefined": > foo = null > foo.bar Uncaught exception: [TypeError] Cannot access property "bar" on null object "foo" at <unknown> > foo = { bar: undefined } > foo.bar.baz Uncaught exception: [TypeError] Cannot access property "baz" on undefined object "foo.bar" at <unknown> Note we certainly don't capture all possible nullish property read accesses here. This just covers cases I've seen most on live websites; we can cover more cases as they arise.
2024-03-29 11:26:10 -04:00
}
LibJS: Port remaining bytecode identifiers to UTF-16
2025-08-07 16:34:36 -04:00
return builder.to_utf16_string();
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
}
return {};
}
Optional<IdentifierTableIndex> Generator::intern_identifier_for_expression(Expression const& expression)
{
LibWeb+LibJS+Tests: Fix typos - act I
2025-03-08 14:20:48 +00:00
if (auto identifier = expression_identifier(expression); identifier.has_value())
return intern_identifier(identifier.release_value());
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
return {};
}
LibJS: Use explicit completion records for try/finally dispatch Each finally scope gets two registers (completion_type and completion_value) that form an explicit completion record. Every path into the finally body sets these before jumping, and a dispatch chain after the finally body routes to the correct continuation. This replaces the old implicit protocol that relied on the exception register, a saved_return_value register, and a scheduled_jump field on ExecutionContext, allowing us to remove: - 5 opcodes (ContinuePendingUnwind, ScheduleJump, LeaveFinally, RestoreScheduledJump, PrepareYield) - 1 reserved register (saved_return_value) - 2 ExecutionContext fields (scheduled_jump, previously_scheduled_jumps)
2026-02-09 01:41:19 +01:00
// Scans outward from boundary_index looking for another ReturnToFinally boundary
// between the current position and the break/continue target. If found, the jump
// must chain through multiple finally blocks via trampolines rather than jumping
// directly to the target after a single finally.
bool Generator::has_outer_finally_before_target(JumpType type, size_t boundary_index) const
{
using enum BlockBoundaryType;
for (size_t j = boundary_index - 1; j > 0; --j) {
auto inner = m_boundaries[j - 1];
if ((type == JumpType::Break && inner == Break) || (type == JumpType::Continue && inner == Continue))
return false;
if (inner == ReturnToFinally)
return true;
}
return false;
}
// Register a jump target with the current FinallyContext. Assigns a unique
// completion_type index, records the target in registered_jumps (so the
// after-finally dispatch chain can route to it), and emits bytecode to set
// completion_type and jump to the finally body.
void Generator::register_jump_in_finally_context(Label target)
{
VERIFY(m_current_finally_context);
auto& finally_context = *m_current_finally_context;
VERIFY(finally_context.next_jump_index < NumericLimits<i32>::max());
auto jump_index = finally_context.next_jump_index++;
finally_context.registered_jumps.append({ jump_index, target });
emit_mov(finally_context.completion_type, add_constant(Value(jump_index)));
emit<Op::Jump>(finally_context.finally_body);
}
// For break/continue through nested finally blocks: creates an intermediate
// "trampoline" block that the inner finally dispatches to, which then continues
// unwinding through the next outer finally. Each trampoline is registered as a
// jump target in the inner finally's dispatch chain.
LibJS: Remove BlockBoundaryType::Unwind With LeaveUnwindContext gone, the Unwind boundary type has no purpose. Remove it from the enum and all start/end boundary calls.
2026-02-09 11:24:01 +01:00
void Generator::emit_trampoline_through_finally(JumpType type)
LibJS: Use explicit completion records for try/finally dispatch Each finally scope gets two registers (completion_type and completion_value) that form an explicit completion record. Every path into the finally body sets these before jumping, and a dispatch chain after the finally body routes to the correct continuation. This replaces the old implicit protocol that relied on the exception register, a saved_return_value register, and a scheduled_jump field on ExecutionContext, allowing us to remove: - 5 opcodes (ContinuePendingUnwind, ScheduleJump, LeaveFinally, RestoreScheduledJump, PrepareYield) - 1 reserved register (saved_return_value) - 2 ExecutionContext fields (scheduled_jump, previously_scheduled_jumps)
2026-02-09 01:41:19 +01:00
{
VERIFY(m_current_finally_context);
auto block_name = MUST(String::formatted("{}.{}", current_block().name(), type == JumpType::Break ? "break"sv : "continue"sv));
auto& trampoline_block = make_block(block_name);
register_jump_in_finally_context(Label { trampoline_block });
switch_to_basic_block(trampoline_block);
m_current_unwind_context = m_current_unwind_context->previous();
m_current_finally_context = m_current_finally_context->parent;
}
LibJS: Deduplicate scoped continue & break bytecode generation The only two differences between these two functions are the name of the block that is created and the specific jump/break handling per boundary.
2023-07-19 19:44:10 +12:00
void Generator::generate_scoped_jump(JumpType type)
LibJS: Generate unwind chains for break in Bytecode This uses a newly added instruction `ScheduleJump` This instruction tells the finally proceeding it, that instead of jumping to it's next block it should jump to the designated block.
2022-11-25 16:15:34 +01:00
{
LibJS: Create static unwind mappings for `BasicBlock`s This is currently only used in the bytecode dump to annotate to where unwinds lead per block, but will be hooked up to the virtual machine in the next commit.
2023-10-19 23:18:54 +02:00
TemporaryChange temp { m_current_unwind_context, m_current_unwind_context };
LibJS: Use explicit completion records for try/finally dispatch Each finally scope gets two registers (completion_type and completion_value) that form an explicit completion record. Every path into the finally body sets these before jumping, and a dispatch chain after the finally body routes to the correct continuation. This replaces the old implicit protocol that relied on the exception register, a saved_return_value register, and a scheduled_jump field on ExecutionContext, allowing us to remove: - 5 opcodes (ContinuePendingUnwind, ScheduleJump, LeaveFinally, RestoreScheduledJump, PrepareYield) - 1 reserved register (saved_return_value) - 2 ExecutionContext fields (scheduled_jump, previously_scheduled_jumps)
2026-02-09 01:41:19 +01:00
TemporaryChange finally_temp { m_current_finally_context, m_current_finally_context };
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
auto environment_stack_offset = m_lexical_environment_register_stack.size();
LibJS: Generate unwind chains for break in Bytecode This uses a newly added instruction `ScheduleJump` This instruction tells the finally proceeding it, that instead of jumping to it's next block it should jump to the designated block.
2022-11-25 16:15:34 +01:00
for (size_t i = m_boundaries.size(); i > 0; --i) {
auto boundary = m_boundaries[i - 1];
using enum BlockBoundaryType;
switch (boundary) {
case Break:
LibJS: Deduplicate scoped continue & break bytecode generation The only two differences between these two functions are the name of the block that is created and the specific jump/break handling per boundary.
2023-07-19 19:44:10 +12:00
if (type == JumpType::Break) {
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
auto const& target_scope = m_breakable_scopes.last();
if (m_current_completion_register.has_value() && target_scope.completion_register.has_value()
&& *m_current_completion_register != *target_scope.completion_register) {
emit_mov(*target_scope.completion_register, *m_current_completion_register);
}
emit<Op::Jump>(target_scope.bytecode_target);
LibJS: Deduplicate scoped continue & break bytecode generation The only two differences between these two functions are the name of the block that is created and the specific jump/break handling per boundary.
2023-07-19 19:44:10 +12:00
return;
}
break;
case Continue:
if (type == JumpType::Continue) {
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
auto const& target_scope = m_continuable_scopes.last();
if (m_current_completion_register.has_value() && target_scope.completion_register.has_value()
&& *m_current_completion_register != *target_scope.completion_register) {
emit_mov(*target_scope.completion_register, *m_current_completion_register);
}
emit<Op::Jump>(target_scope.bytecode_target);
LibJS: Deduplicate scoped continue & break bytecode generation The only two differences between these two functions are the name of the block that is created and the specific jump/break handling per boundary.
2023-07-19 19:44:10 +12:00
return;
}
break;
LibJS: Generate unwind chains for break in Bytecode This uses a newly added instruction `ScheduleJump` This instruction tells the finally proceeding it, that instead of jumping to it's next block it should jump to the designated block.
2022-11-25 16:15:34 +01:00
case LeaveLexicalEnvironment:
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
--environment_stack_offset;
emit<Bytecode::Op::SetLexicalEnvironment>(m_lexical_environment_register_stack[environment_stack_offset - 1]);
LibJS: Generate unwind chains for break in Bytecode This uses a newly added instruction `ScheduleJump` This instruction tells the finally proceeding it, that instead of jumping to it's next block it should jump to the designated block.
2022-11-25 16:15:34 +01:00
break;
case ReturnToFinally: {
LibJS: Use explicit completion records for try/finally dispatch Each finally scope gets two registers (completion_type and completion_value) that form an explicit completion record. Every path into the finally body sets these before jumping, and a dispatch chain after the finally body routes to the correct continuation. This replaces the old implicit protocol that relied on the exception register, a saved_return_value register, and a scheduled_jump field on ExecutionContext, allowing us to remove: - 5 opcodes (ContinuePendingUnwind, ScheduleJump, LeaveFinally, RestoreScheduledJump, PrepareYield) - 1 reserved register (saved_return_value) - 2 ExecutionContext fields (scheduled_jump, previously_scheduled_jumps)
2026-02-09 01:41:19 +01:00
VERIFY(m_current_finally_context);
if (!has_outer_finally_before_target(type, i)) {
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
auto const& target_scope = type == JumpType::Break ? m_breakable_scopes.last() : m_continuable_scopes.last();
if (m_current_completion_register.has_value() && target_scope.completion_register.has_value()
&& *m_current_completion_register != *target_scope.completion_register) {
emit_mov(*target_scope.completion_register, *m_current_completion_register);
}
register_jump_in_finally_context(target_scope.bytecode_target);
LibJS: Use explicit completion records for try/finally dispatch Each finally scope gets two registers (completion_type and completion_value) that form an explicit completion record. Every path into the finally body sets these before jumping, and a dispatch chain after the finally body routes to the correct continuation. This replaces the old implicit protocol that relied on the exception register, a saved_return_value register, and a scheduled_jump field on ExecutionContext, allowing us to remove: - 5 opcodes (ContinuePendingUnwind, ScheduleJump, LeaveFinally, RestoreScheduledJump, PrepareYield) - 1 reserved register (saved_return_value) - 2 ExecutionContext fields (scheduled_jump, previously_scheduled_jumps)
2026-02-09 01:41:19 +01:00
return;
}
LibJS: Remove BlockBoundaryType::Unwind With LeaveUnwindContext gone, the Unwind boundary type has no purpose. Remove it from the enum and all start/end boundary calls.
2026-02-09 11:24:01 +01:00
emit_trampoline_through_finally(type);
LibJS: Generate unwind chains for break in Bytecode This uses a newly added instruction `ScheduleJump` This instruction tells the finally proceeding it, that instead of jumping to it's next block it should jump to the designated block.
2022-11-25 16:15:34 +01:00
break;
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
}
case LeaveFinally:
break;
LibJS: Generate unwind chains for break in Bytecode This uses a newly added instruction `ScheduleJump` This instruction tells the finally proceeding it, that instead of jumping to it's next block it should jump to the designated block.
2022-11-25 16:15:34 +01:00
}
}
VERIFY_NOT_REACHED();
}
LibJS: Use FlyString in PropertyKey instead of DeprecatedFlyString This required dealing with *substantial* fallout.
2025-03-18 18:08:02 -05:00
void Generator::generate_labelled_jump(JumpType type, FlyString const& label)
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
{
LibJS: Create static unwind mappings for `BasicBlock`s This is currently only used in the bytecode dump to annotate to where unwinds lead per block, but will be hooked up to the virtual machine in the next commit.
2023-10-19 23:18:54 +02:00
TemporaryChange temp { m_current_unwind_context, m_current_unwind_context };
LibJS: Use explicit completion records for try/finally dispatch Each finally scope gets two registers (completion_type and completion_value) that form an explicit completion record. Every path into the finally body sets these before jumping, and a dispatch chain after the finally body routes to the correct continuation. This replaces the old implicit protocol that relied on the exception register, a saved_return_value register, and a scheduled_jump field on ExecutionContext, allowing us to remove: - 5 opcodes (ContinuePendingUnwind, ScheduleJump, LeaveFinally, RestoreScheduledJump, PrepareYield) - 1 reserved register (saved_return_value) - 2 ExecutionContext fields (scheduled_jump, previously_scheduled_jumps)
2026-02-09 01:41:19 +01:00
TemporaryChange finally_temp { m_current_finally_context, m_current_finally_context };
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
size_t current_boundary = m_boundaries.size();
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
auto environment_stack_offset = m_lexical_environment_register_stack.size();
LibJS: Deduplicate labelled continue & break bytecode generation Similar to the scoped continue and break, the only two differences between these functions is the scope that is scanned for a matching label, and the specific handling of a continue/break boundary.
2023-07-19 20:06:25 +12:00
auto const& jumpable_scopes = type == JumpType::Continue ? m_continuable_scopes : m_breakable_scopes;
for (auto const& jumpable_scope : jumpable_scopes.in_reverse()) {
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
for (; current_boundary > 0; --current_boundary) {
auto boundary = m_boundaries[current_boundary - 1];
LibJS: Remove BlockBoundaryType::Unwind With LeaveUnwindContext gone, the Unwind boundary type has no purpose. Remove it from the enum and all start/end boundary calls.
2026-02-09 11:24:01 +01:00
if (boundary == BlockBoundaryType::LeaveLexicalEnvironment) {
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
--environment_stack_offset;
emit<Bytecode::Op::SetLexicalEnvironment>(m_lexical_environment_register_stack[environment_stack_offset - 1]);
LibJS: Intercept returns through finally blocks in Bytecode This is still not perfect, as we now actually crash in the `try-finally-continue` tests, while we now succeed all `try-catch-finally-*` tests. Note that we do not yet go through the finally block when exiting the unwind context through a break or continue.
2022-11-13 20:56:53 +01:00
} else if (boundary == BlockBoundaryType::ReturnToFinally) {
LibJS: Use explicit completion records for try/finally dispatch Each finally scope gets two registers (completion_type and completion_value) that form an explicit completion record. Every path into the finally body sets these before jumping, and a dispatch chain after the finally body routes to the correct continuation. This replaces the old implicit protocol that relied on the exception register, a saved_return_value register, and a scheduled_jump field on ExecutionContext, allowing us to remove: - 5 opcodes (ContinuePendingUnwind, ScheduleJump, LeaveFinally, RestoreScheduledJump, PrepareYield) - 1 reserved register (saved_return_value) - 2 ExecutionContext fields (scheduled_jump, previously_scheduled_jumps)
2026-02-09 01:41:19 +01:00
VERIFY(m_current_finally_context);
if (!has_outer_finally_before_target(type, current_boundary) && jumpable_scope.language_label_set.contains_slow(label)) {
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
if (m_current_completion_register.has_value() && jumpable_scope.completion_register.has_value()
&& *m_current_completion_register != *jumpable_scope.completion_register) {
emit_mov(*jumpable_scope.completion_register, *m_current_completion_register);
}
LibJS: Use explicit completion records for try/finally dispatch Each finally scope gets two registers (completion_type and completion_value) that form an explicit completion record. Every path into the finally body sets these before jumping, and a dispatch chain after the finally body routes to the correct continuation. This replaces the old implicit protocol that relied on the exception register, a saved_return_value register, and a scheduled_jump field on ExecutionContext, allowing us to remove: - 5 opcodes (ContinuePendingUnwind, ScheduleJump, LeaveFinally, RestoreScheduledJump, PrepareYield) - 1 reserved register (saved_return_value) - 2 ExecutionContext fields (scheduled_jump, previously_scheduled_jumps)
2026-02-09 01:41:19 +01:00
register_jump_in_finally_context(jumpable_scope.bytecode_target);
return;
}
LibJS: Remove BlockBoundaryType::Unwind With LeaveUnwindContext gone, the Unwind boundary type has no purpose. Remove it from the enum and all start/end boundary calls.
2026-02-09 11:24:01 +01:00
emit_trampoline_through_finally(type);
LibJS: Deduplicate labelled continue & break bytecode generation Similar to the scoped continue and break, the only two differences between these functions is the scope that is scanned for a matching label, and the specific handling of a continue/break boundary.
2023-07-19 20:06:25 +12:00
} else if ((type == JumpType::Continue && boundary == BlockBoundaryType::Continue) || (type == JumpType::Break && boundary == BlockBoundaryType::Break)) {
// Make sure we don't process this boundary twice if the current jumpable scope doesn't contain the target label.
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
--current_boundary;
break;
}
}
LibJS: Deduplicate labelled continue & break bytecode generation Similar to the scoped continue and break, the only two differences between these functions is the scope that is scanned for a matching label, and the specific handling of a continue/break boundary.
2023-07-19 20:06:25 +12:00
if (jumpable_scope.language_label_set.contains_slow(label)) {
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
if (m_current_completion_register.has_value() && jumpable_scope.completion_register.has_value()
&& *m_current_completion_register != *jumpable_scope.completion_register) {
emit_mov(*jumpable_scope.completion_register, *m_current_completion_register);
}
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
emit<Op::Jump>(jumpable_scope.bytecode_target);
LibJS: Generate unwind chains for break in Bytecode This uses a newly added instruction `ScheduleJump` This instruction tells the finally proceeding it, that instead of jumping to it's next block it should jump to the designated block.
2022-11-25 16:15:34 +01:00
return;
}
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
}
LibJS: Deduplicate labelled continue & break bytecode generation Similar to the scoped continue and break, the only two differences between these functions is the scope that is scanned for a matching label, and the specific handling of a continue/break boundary.
2023-07-19 20:06:25 +12:00
// We must have a jumpable scope available that contains the label, as this should be enforced by the parser.
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
VERIFY_NOT_REACHED();
}
LibJS: Deduplicate labelled continue & break bytecode generation Similar to the scoped continue and break, the only two differences between these functions is the scope that is scanned for a matching label, and the specific handling of a continue/break boundary.
2023-07-19 20:06:25 +12:00
void Generator::generate_break()
{
generate_scoped_jump(JumpType::Break);
}
LibJS: Use FlyString in PropertyKey instead of DeprecatedFlyString This required dealing with *substantial* fallout.
2025-03-18 18:08:02 -05:00
void Generator::generate_break(FlyString const& break_label)
LibJS: Deduplicate labelled continue & break bytecode generation Similar to the scoped continue and break, the only two differences between these functions is the scope that is scanned for a matching label, and the specific handling of a continue/break boundary.
2023-07-19 20:06:25 +12:00
{
generate_labelled_jump(JumpType::Break, break_label);
}
LibJS: Generate unwind chains for continue in Bytecode This works similar to `break` The `try-finally-continue` still do not pass with this, likely because of binding issues.
2022-11-25 16:35:39 +01:00
void Generator::generate_continue()
{
LibJS: Deduplicate scoped continue & break bytecode generation The only two differences between these two functions are the name of the block that is created and the specific jump/break handling per boundary.
2023-07-19 19:44:10 +12:00
generate_scoped_jump(JumpType::Continue);
LibJS: Generate unwind chains for continue in Bytecode This works similar to `break` The `try-finally-continue` still do not pass with this, likely because of binding issues.
2022-11-25 16:35:39 +01:00
}
LibJS: Use FlyString in PropertyKey instead of DeprecatedFlyString This required dealing with *substantial* fallout.
2025-03-18 18:08:02 -05:00
void Generator::generate_continue(FlyString const& continue_label)
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
{
LibJS: Deduplicate labelled continue & break bytecode generation Similar to the scoped continue and break, the only two differences between these functions is the scope that is scanned for a matching label, and the specific handling of a continue/break boundary.
2023-07-19 20:06:25 +12:00
generate_labelled_jump(JumpType::Continue, continue_label);
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
}
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
void Generator::push_home_object(ScopedOperand object)
LibJS/Bytecode: Set "home object" of functions within object expression We manage this by having a stack of home objects in Generator, and then adding an optional home object parameter to the NewFunction instruction.
2023-06-16 10:25:05 +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
m_home_objects.append(object);
LibJS/Bytecode: Set "home object" of functions within object expression We manage this by having a stack of home objects in Generator, and then adding an optional home object parameter to the NewFunction instruction.
2023-06-16 10:25:05 +02:00
}
void Generator::pop_home_object()
{
m_home_objects.take_last();
}
LibJS: Don't set [[HomeObject]] for non-method object properties This fixes an issue where we'd incorrectly retain objects via the [[HomeObject]] slot. This common pattern was affected: Object.defineProperty(o, "foo", { get: function() { return 123; } }); Above, the object literal would get assigned to the [[HomeObject]] slot even though "get" is not a "method" per the spec. This frees about 30,000 objects on my x.com home feed.
2025-12-17 00:22:20 -06:00
void Generator::emit_new_function(ScopedOperand dst, FunctionExpression const& function_node, Optional<IdentifierTableIndex> lhs_name, bool is_method)
LibJS/Bytecode: Set "home object" of functions within object expression We manage this by having a stack of home objects in Generator, and then adding an optional home object parameter to the NewFunction instruction.
2023-06-16 10:25:05 +02:00
{
LibJS: Pre-create SharedFunctionInstanceData in NewFunction Replace the FunctionNode const& stored on the NewFunction bytecode instruction with an index into a table of pre-created SharedFunctionInstanceData objects on the Executable. During bytecode compilation, we now eagerly create SharedFunctionInstanceData for each function that will be instantiated by NewFunction, and store it on both the FunctionNode (for caching) and the Executable (for GC tracing). At runtime, NewFunction simply looks up the SharedFunctionInstanceData by index and calls create_from_function_data() directly, bypassing the AST entirely. This removes one of the main reasons the AST had to stay alive after compilation. The instantiate_ordinary_function_expression() helper in Interpreter.cpp is removed as its non-trivial code path (creating a scope for named function expressions) was dead code -- it was only called when !has_name(), so the has_own_name branch never executed.
2026-02-10 23:02:46 +01:00
Utf16FlyString name;
if (function_node.has_name())
name = function_node.name();
else if (lhs_name.has_value())
name = m_identifier_table->get(lhs_name.value());
auto shared_data = ensure_shared_function_data(m_vm, function_node, move(name));
auto data_index = register_shared_function_data(shared_data);
LibJS: Don't set [[HomeObject]] for non-method object properties This fixes an issue where we'd incorrectly retain objects via the [[HomeObject]] slot. This common pattern was affected: Object.defineProperty(o, "foo", { get: function() { return 123; } }); Above, the object literal would get assigned to the [[HomeObject]] slot even though "get" is not a "method" per the spec. This frees about 30,000 objects on my x.com home feed.
2025-12-17 00:22:20 -06:00
if (!is_method || m_home_objects.is_empty()) {
LibJS: Pre-create SharedFunctionInstanceData in NewFunction Replace the FunctionNode const& stored on the NewFunction bytecode instruction with an index into a table of pre-created SharedFunctionInstanceData objects on the Executable. During bytecode compilation, we now eagerly create SharedFunctionInstanceData for each function that will be instantiated by NewFunction, and store it on both the FunctionNode (for caching) and the Executable (for GC tracing). At runtime, NewFunction simply looks up the SharedFunctionInstanceData by index and calls create_from_function_data() directly, bypassing the AST entirely. This removes one of the main reasons the AST had to stay alive after compilation. The instantiate_ordinary_function_expression() helper in Interpreter.cpp is removed as its non-trivial code path (creating a scope for named function expressions) was dead code -- it was only called when !has_name(), so the has_own_name branch never executed.
2026-02-10 23:02:46 +01:00
emit<Op::NewFunction>(dst, data_index, lhs_name, OptionalNone {});
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 {
LibJS: Pre-create SharedFunctionInstanceData in NewFunction Replace the FunctionNode const& stored on the NewFunction bytecode instruction with an index into a table of pre-created SharedFunctionInstanceData objects on the Executable. During bytecode compilation, we now eagerly create SharedFunctionInstanceData for each function that will be instantiated by NewFunction, and store it on both the FunctionNode (for caching) and the Executable (for GC tracing). At runtime, NewFunction simply looks up the SharedFunctionInstanceData by index and calls create_from_function_data() directly, bypassing the AST entirely. This removes one of the main reasons the AST had to stay alive after compilation. The instantiate_ordinary_function_expression() helper in Interpreter.cpp is removed as its non-trivial code path (creating a scope for named function expressions) was dead code -- it was only called when !has_name(), so the has_own_name branch never executed.
2026-02-10 23:02:46 +01:00
emit<Op::NewFunction>(dst, data_index, lhs_name, m_home_objects.last());
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: Add codegen for "named evaluation if anonymous function" This gives anonymous functions the name from the LHS they are being assigned to. 171 new passes on test262. :^)
2023-06-23 14:27:42 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
ScopedOperand Generator::emit_named_evaluation_if_anonymous_function(Expression const& expression, Optional<IdentifierTableIndex> lhs_name, Optional<ScopedOperand> preferred_dst, bool is_method)
LibJS/Bytecode: Add codegen for "named evaluation if anonymous function" This gives anonymous functions the name from the LHS they are being assigned to. 171 new passes on test262. :^)
2023-06-23 14:27:42 +02:00
{
if (is<FunctionExpression>(expression)) {
auto const& function_expression = static_cast<FunctionExpression const&>(expression);
if (!function_expression.has_name()) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return function_expression.generate_bytecode_with_lhs_name(*this, move(lhs_name), preferred_dst, is_method).value();
LibJS/Bytecode: Add codegen for "named evaluation if anonymous function" This gives anonymous functions the name from the LHS they are being assigned to. 171 new passes on test262. :^)
2023-06-23 14:27:42 +02:00
}
}
if (is<ClassExpression>(expression)) {
auto const& class_expression = static_cast<ClassExpression const&>(expression);
if (!class_expression.has_name()) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return class_expression.generate_bytecode_with_lhs_name(*this, move(lhs_name), preferred_dst).value();
LibJS/Bytecode: Add codegen for "named evaluation if anonymous function" This gives anonymous functions the name from the LHS they are being assigned to. 171 new passes on test262. :^)
2023-06-23 14:27:42 +02:00
}
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return expression.generate_bytecode(*this, preferred_dst).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: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
void Generator::emit_get_by_id(ScopedOperand dst, ScopedOperand base, PropertyKeyTableIndex property_key_table_index, Optional<IdentifierTableIndex> base_identifier)
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: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
auto& property_key = m_property_key_table->get(property_key_table_index);
if (property_key.is_string() && property_key.as_string() == "length"sv) {
m_length_identifier = property_key_table_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
emit<Op::GetLength>(dst, base, move(base_identifier), m_next_property_lookup_cache++);
return;
}
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
emit<Op::GetById>(dst, base, property_key_table_index, move(base_identifier), m_next_property_lookup_cache++);
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: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
void Generator::emit_get_by_id_with_this(ScopedOperand dst, ScopedOperand base, PropertyKeyTableIndex id, ScopedOperand this_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: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
if (m_property_key_table->get(id).as_string() == "length"sv) {
LibJS: Cache length identifier for GetLengthWithThis We cached the length identifier for GetLength, but not GetLengthWithThis. This caused an `has_value()` verification failure when accessing super.length. Found by Fuzzilli.
2025-04-07 12:35:23 +01:00
m_length_identifier = id;
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
emit<Op::GetLengthWithThis>(dst, base, this_value, m_next_property_lookup_cache++);
return;
}
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
emit<Op::GetByIdWithThis>(dst, base, id, this_value, m_next_property_lookup_cache++);
LibJS/Bytecode: Set "home object" of functions within object expression We manage this by having a stack of home objects in Generator, and then adding an optional home object parameter to the NewFunction instruction.
2023-06-16 10:25:05 +02:00
}
LibJS: Emit GetById instead of GetByValue when key is string literal Basically convert o["foo"] into o.foo when emitting bytecode. These are effectively the same thing, and the latter format opts into using an inline cache for the property lookups.
2025-04-03 14:18:24 +02:00
void Generator::emit_get_by_value(ScopedOperand dst, ScopedOperand base, ScopedOperand property, Optional<IdentifierTableIndex> base_identifier)
{
if (property.operand().is_constant() && get_constant(property).is_string()) {
auto property_key = MUST(get_constant(property).to_property_key(vm()));
if (property_key.is_string()) {
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
emit_get_by_id(dst, base, intern_property_key(property_key.as_string()), base_identifier);
LibJS: Emit GetById instead of GetByValue when key is string literal Basically convert o["foo"] into o.foo when emitting bytecode. These are effectively the same thing, and the latter format opts into using an inline cache for the property lookups.
2025-04-03 14:18:24 +02:00
return;
}
}
emit<Op::GetByValue>(dst, base, property, base_identifier);
}
void Generator::emit_get_by_value_with_this(ScopedOperand dst, ScopedOperand base, ScopedOperand property, ScopedOperand this_value)
{
if (property.operand().is_constant() && get_constant(property).is_string()) {
auto property_key = MUST(get_constant(property).to_property_key(vm()));
if (property_key.is_string()) {
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
emit_get_by_id_with_this(dst, base, intern_property_key(property_key.as_string()), this_value);
LibJS: Emit GetById instead of GetByValue when key is string literal Basically convert o["foo"] into o.foo when emitting bytecode. These are effectively the same thing, and the latter format opts into using an inline cache for the property lookups.
2025-04-03 14:18:24 +02:00
return;
}
}
emit<Op::GetByValueWithThis>(dst, base, property, this_value);
}
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
void Generator::emit_put_by_id(Operand base, PropertyKeyTableIndex property, Operand src, PutKind kind, u32 cache_index, Optional<IdentifierTableIndex> 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
{
LibJS: Split PutBy* instructions into specialized per-kind variants This allows the compiler to fold away lots of unused code for each kind. 1.10x speed-up on MicroBench/pic-add-own.js :^)
2025-10-10 12:09:34 +02:00
#define EMIT_PUT_BY_ID(kind) \
case PutKind::kind: \
emit<Op::Put##kind##ById>(base, property, src, cache_index, move(base_identifier)); \
break;
switch (kind) {
JS_ENUMERATE_PUT_KINDS(EMIT_PUT_BY_ID)
default:
VERIFY_NOT_REACHED();
}
#undef EMIT_PUT_BY_ID
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
}
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
void Generator::emit_put_by_value(ScopedOperand base, ScopedOperand property, ScopedOperand src, Bytecode::PutKind kind, Optional<IdentifierTableIndex> base_identifier)
LibJS: Emit PutById instead of PutByValue when key is string literal Basically convert o["foo"]=x into o.foo=x when emitting bytecode. These are effectively the same thing, and the latter format opts into using an inline cache for the property lookups.
2025-04-03 14:29:44 +02:00
{
if (property.operand().is_constant() && get_constant(property).is_string()) {
auto property_key = MUST(get_constant(property).to_property_key(vm()));
if (property_key.is_string()) {
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
emit_put_by_id(base, intern_property_key(property_key.as_string()), src, kind, m_next_property_lookup_cache++, base_identifier);
LibJS: Emit PutById instead of PutByValue when key is string literal Basically convert o["foo"]=x into o.foo=x when emitting bytecode. These are effectively the same thing, and the latter format opts into using an inline cache for the property lookups.
2025-04-03 14:29:44 +02:00
return;
}
}
LibJS: Split PutBy* instructions into specialized per-kind variants This allows the compiler to fold away lots of unused code for each kind. 1.10x speed-up on MicroBench/pic-add-own.js :^)
2025-10-10 12:09:34 +02:00
#define EMIT_PUT_BY_VALUE(kind) \
case PutKind::kind: \
emit<Op::Put##kind##ByValue>(base, property, src, move(base_identifier)); \
break;
switch (kind) {
JS_ENUMERATE_PUT_KINDS(EMIT_PUT_BY_VALUE)
default:
VERIFY_NOT_REACHED();
}
#undef EMIT_PUT_BY_VALUE
LibJS: Emit PutById instead of PutByValue when key is string literal Basically convert o["foo"]=x into o.foo=x when emitting bytecode. These are effectively the same thing, and the latter format opts into using an inline cache for the property lookups.
2025-04-03 14:29:44 +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
void Generator::emit_put_by_value_with_this(ScopedOperand base, ScopedOperand property, ScopedOperand this_value, ScopedOperand src, Bytecode::PutKind kind)
LibJS: Emit PutById instead of PutByValue when key is string literal Basically convert o["foo"]=x into o.foo=x when emitting bytecode. These are effectively the same thing, and the latter format opts into using an inline cache for the property lookups.
2025-04-03 14:29:44 +02:00
{
if (property.operand().is_constant() && get_constant(property).is_string()) {
auto property_key = MUST(get_constant(property).to_property_key(vm()));
if (property_key.is_string()) {
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
#define EMIT_PUT_BY_ID_WITH_THIS(kind) \
case PutKind::kind: \
emit<Op::Put##kind##ByIdWithThis>(base, this_value, intern_property_key(property_key), src, m_next_property_lookup_cache++); \
LibJS: Split PutBy* instructions into specialized per-kind variants This allows the compiler to fold away lots of unused code for each kind. 1.10x speed-up on MicroBench/pic-add-own.js :^)
2025-10-10 12:09:34 +02:00
break;
switch (kind) {
JS_ENUMERATE_PUT_KINDS(EMIT_PUT_BY_ID_WITH_THIS)
default:
VERIFY_NOT_REACHED();
}
#undef EMIT_PUT_BY_ID_WITH_THIS
LibJS: Emit PutById instead of PutByValue when key is string literal Basically convert o["foo"]=x into o.foo=x when emitting bytecode. These are effectively the same thing, and the latter format opts into using an inline cache for the property lookups.
2025-04-03 14:29:44 +02:00
return;
}
}
LibJS: Split PutBy* instructions into specialized per-kind variants This allows the compiler to fold away lots of unused code for each kind. 1.10x speed-up on MicroBench/pic-add-own.js :^)
2025-10-10 12:09:34 +02:00
#define EMIT_PUT_BY_VALUE_WITH_THIS(kind) \
case PutKind::kind: \
emit<Op::Put##kind##ByValueWithThis>(base, property, this_value, src); \
break;
switch (kind) {
JS_ENUMERATE_PUT_KINDS(EMIT_PUT_BY_VALUE_WITH_THIS)
default:
VERIFY_NOT_REACHED();
}
#undef EMIT_PUT_BY_VALUE_WITH_THIS
LibJS: Emit PutById instead of PutByValue when key is string literal Basically convert o["foo"]=x into o.foo=x when emitting bytecode. These are effectively the same thing, and the latter format opts into using an inline cache for the property lookups.
2025-04-03 14:29:44 +02:00
}
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
void Generator::emit_iterator_value(ScopedOperand dst, ScopedOperand result)
LibJS/Bytecode: Cache object own property accesses The instructions GetById and GetByIdWithThis now remember the last-seen Shape, and if we see the same object again, we reuse the property offset from last time without doing a new lookup. This allows us to use Object::get_direct(), bypassing the entire lookup machinery and saving lots of time. ~23% speed-up on Kraken/ai-astar.js :^)
2023-07-08 17:43:26 +02:00
{
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
emit_get_by_id(dst, result, intern_property_key("value"_utf16_fly_string));
LibJS/Bytecode: Cache object own property accesses The instructions GetById and GetByIdWithThis now remember the last-seen Shape, and if we see the same object again, we reuse the property offset from last time without doing a new lookup. This allows us to use Object::get_direct(), bypassing the entire lookup machinery and saving lots of time. ~23% speed-up on Kraken/ai-astar.js :^)
2023-07-08 17:43:26 +02:00
}
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
void Generator::emit_iterator_complete(ScopedOperand dst, ScopedOperand result)
LibJS/Bytecode: Cache object own property accesses The instructions GetById and GetByIdWithThis now remember the last-seen Shape, and if we see the same object again, we reuse the property offset from last time without doing a new lookup. This allows us to use Object::get_direct(), bypassing the entire lookup machinery and saving lots of time. ~23% speed-up on Kraken/ai-astar.js :^)
2023-07-08 17:43:26 +02:00
{
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
emit_get_by_id(dst, result, intern_property_key("done"_utf16_fly_string));
LibJS/Bytecode: Cache object own property accesses The instructions GetById and GetByIdWithThis now remember the last-seen Shape, and if we see the same object again, we reuse the property offset from last time without doing a new lookup. This allows us to use Object::get_direct(), bypassing the entire lookup machinery and saving lots of time. ~23% speed-up on Kraken/ai-astar.js :^)
2023-07-08 17:43:26 +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
bool Generator::is_local_initialized(u32 local_index) const
LibJS: Remove dedicated iterator result instructions in favor of GetById When iterating over an iterable, we get back a JS object with the fields "value" and "done". Before this change, we've had two dedicated instructions for retrieving the two fields: IteratorResultValue and IteratorResultDone. These had no fast path whatsoever and just did a generic [[Get]] access to fetch the corresponding property values. By replacing the instructions with GetById("value") and GetById("done"), they instantly get caching and JIT fast paths for free, making iterating over iterables much faster. :^) 26% speed-up on this microbenchmark: function go(a) { for (const p of a) { } } const a = []; a.length = 1_000_000; go(a);
2023-12-07 16:12:12 +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 m_initialized_locals.find(local_index) != m_initialized_locals.end();
LibJS: Remove dedicated iterator result instructions in favor of GetById When iterating over an iterable, we get back a JS object with the fields "value" and "done". Before this change, we've had two dedicated instructions for retrieving the two fields: IteratorResultValue and IteratorResultDone. These had no fast path whatsoever and just did a generic [[Get]] access to fetch the corresponding property values. By replacing the instructions with GetById("value") and GetById("done"), they instantly get caching and JIT fast paths for free, making iterating over iterables much faster. :^) 26% speed-up on this microbenchmark: function go(a) { for (const p of a) { } } const a = []; a.length = 1_000_000; go(a);
2023-12-07 16:12:12 +01:00
}
LibJS: Skip allocating locals for arguments that allowed to be local This allows us to get rid of instructions that move arguments to locals and allocate smaller JS::Value vector in ExecutionContext by reusing slots that were already allocated for arguments. With this change for following function: ```js function f(x, y) { return x + y; } ``` we now produce following bytecode: ``` [ 0] 0: Add dst:reg6, lhs:arg0, rhs:arg1 [ 10] Return value:reg6 ``` instead of: ``` [ 0] 0: GetArgument 0, dst:x~1 [ 10] GetArgument 1, dst:y~0 [ 20] Add dst:reg6, lhs:x~1, rhs:y~0 [ 30] Return value:reg6 ```
2025-04-25 17:10:47 +02:00
bool Generator::is_local_initialized(Identifier::Local const& local) const
LibJS: Remove dedicated iterator result instructions in favor of GetById When iterating over an iterable, we get back a JS object with the fields "value" and "done". Before this change, we've had two dedicated instructions for retrieving the two fields: IteratorResultValue and IteratorResultDone. These had no fast path whatsoever and just did a generic [[Get]] access to fetch the corresponding property values. By replacing the instructions with GetById("value") and GetById("done"), they instantly get caching and JIT fast paths for free, making iterating over iterables much faster. :^) 26% speed-up on this microbenchmark: function go(a) { for (const p of a) { } } const a = []; a.length = 1_000_000; go(a);
2023-12-07 16:12:12 +01:00
{
LibJS: Skip allocating locals for arguments that allowed to be local This allows us to get rid of instructions that move arguments to locals and allocate smaller JS::Value vector in ExecutionContext by reusing slots that were already allocated for arguments. With this change for following function: ```js function f(x, y) { return x + y; } ``` we now produce following bytecode: ``` [ 0] 0: Add dst:reg6, lhs:arg0, rhs:arg1 [ 10] Return value:reg6 ``` instead of: ``` [ 0] 0: GetArgument 0, dst:x~1 [ 10] GetArgument 1, dst:y~0 [ 20] Add dst:reg6, lhs:x~1, rhs:y~0 [ 30] Return value:reg6 ```
2025-04-25 17:10:47 +02:00
if (local.is_variable())
return m_initialized_locals.find(local.index) != m_initialized_locals.end();
if (local.is_argument())
return m_initialized_arguments.find(local.index) != m_initialized_arguments.end();
return true;
}
void Generator::set_local_initialized(Identifier::Local const& local)
{
if (local.is_variable()) {
m_initialized_locals.set(local.index);
} else if (local.is_argument()) {
m_initialized_arguments.set(local.index);
} else {
VERIFY_NOT_REACHED();
}
LibJS: Remove dedicated iterator result instructions in favor of GetById When iterating over an iterable, we get back a JS object with the fields "value" and "done". Before this change, we've had two dedicated instructions for retrieving the two fields: IteratorResultValue and IteratorResultDone. These had no fast path whatsoever and just did a generic [[Get]] access to fetch the corresponding property values. By replacing the instructions with GetById("value") and GetById("done"), they instantly get caching and JIT fast paths for free, making iterating over iterables much faster. :^) 26% speed-up on this microbenchmark: function go(a) { for (const p of a) { } } const a = []; a.length = 1_000_000; go(a);
2023-12-07 16:12:12 +01:00
}
LibJS: Remove #include <AST.h> from SharedFunctionInstanceData.h Extract FunctionParsingInsights into its own header and introduce FunctionLocal as a standalone mirror of Identifier::Local. This allows SharedFunctionInstanceData.h to avoid pulling in the full AST type hierarchy, reducing transitive include bloat. The AST.h include is kept in SharedFunctionInstanceData.cpp where it's needed for the constructor that accesses AST node types.
2026-02-11 01:20:54 +01:00
void Generator::set_local_initialized(FunctionLocal const& local)
{
if (local.is_variable()) {
m_initialized_locals.set(local.index);
} else if (local.is_argument()) {
m_initialized_arguments.set(local.index);
} else {
VERIFY_NOT_REACHED();
}
}
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
bool Generator::is_local_lexically_declared(Identifier::Local const& local) const
{
if (local.is_argument())
return false;
return m_local_variables[local.index].declaration_kind == LocalVariable::DeclarationKind::LetOrConst;
}
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
ScopedOperand Generator::get_this(Optional<ScopedOperand> preferred_dst)
LibJS/Bytecode: Only emit ResolveThisBinding once per basic block Once executed, this instruction will always produce the same result in subsequent executions, so it's okay to cache it. Unfortunately it may throw, so we can't just hoist it to the top of every executable, since that would break observable execution order.
2024-05-07 12:16:37 +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
if (m_current_basic_block->has_resolved_this())
return this_value();
if (m_root_basic_blocks[0]->has_resolved_this()) {
m_current_basic_block->set_has_resolved_this();
return this_value();
LibJS/Bytecode: Allow all basic blocks to use cached `this` from block 0 The first block in every executable will always execute first, so if it ends up doing a ResolveThisBinding, it's fine for all other blocks within the same executable to use the same `this` value.
2024-05-07 20:01:31 +02:00
}
LibJS/Bytecode: Don't generate ResolveThisBinding if not needed Functions that don't have a FunctionEnvironment will get their `this` value from the ExecutionContext. This patch stops generating ResolveThisBinding instructions at all for functions like that, and instead pre-populates the `this` register when entering a new bytecode executable.
2024-05-31 21:00:15 +02:00
// OPTIMIZATION: If we're compiling a function that doesn't allocate a FunctionEnvironment,
// it will always have the same `this` value as the outer function,
// and so the `this` value is already in the `this` register!
LibJS/Bytecode: Make compilation use SharedFunctionInstanceData instead All the data we need for compilation is in SharedFunctionInstanceData, so we shouldn't depend on ECMAScriptFunctionObject. Allows NativeJavaScriptBackedFunction to compile bytecode.
2025-11-06 17:26:02 +00:00
if (m_shared_function_instance_data && !m_shared_function_instance_data->m_function_environment_needed)
LibJS/Bytecode: Don't generate ResolveThisBinding if not needed Functions that don't have a FunctionEnvironment will get their `this` value from the ExecutionContext. This patch stops generating ResolveThisBinding instructions at all for functions like that, and instead pre-populates the `this` register when entering a new bytecode executable.
2024-05-31 21:00:15 +02:00
return this_value();
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto dst = preferred_dst.has_value() ? preferred_dst.value() : allocate_register();
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
emit<Bytecode::Op::ResolveThisBinding>();
m_current_basic_block->set_has_resolved_this();
return this_value();
LibJS/Bytecode: Only emit ResolveThisBinding once per basic block Once executed, this instruction will always produce the same result in subsequent executions, so it's okay to cache it. Unfortunately it may throw, so we can't just hoist it to the top of every executable, since that would break observable execution order.
2024-05-07 12:16:37 +02:00
}
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
ScopedOperand Generator::accumulator()
{
return m_accumulator;
}
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
ScopedOperand Generator::this_value()
{
return m_this_value;
}
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
bool Generator::fuse_compare_and_jump(ScopedOperand const& condition, Label true_target, Label false_target)
{
auto& last_instruction = *reinterpret_cast<Instruction const*>(m_current_basic_block->data() + m_current_basic_block->last_instruction_start_offset());
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
if (last_instruction.type() == Instruction::Type::op_TitleCase) { \
auto& comparison = static_cast<Op::op_TitleCase const&>(last_instruction); \
VERIFY(comparison.dst() == condition); \
auto lhs = comparison.lhs(); \
auto rhs = comparison.rhs(); \
m_current_basic_block->rewind(); \
emit<Op::Jump##op_TitleCase>(lhs, rhs, true_target, false_target); \
return true; \
}
JS_ENUMERATE_COMPARISON_OPS(HANDLE_COMPARISON_OP);
#undef HANDLE_COMPARISON_OP
return false;
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
void Generator::emit_todo(StringView message)
{
auto error_message = MUST(String::formatted("TODO: {}", message));
auto message_string = intern_string(Utf16String::from_utf8(error_message));
auto error_register = allocate_register();
emit<Op::NewTypeError>(error_register, message_string);
perform_needed_unwinds<Op::Throw>();
emit<Op::Throw>(error_register);
// Switch to a new block so subsequent codegen doesn't crash trying to
// emit into a terminated block.
auto& dead_block = make_block("dead"_string);
switch_to_basic_block(dead_block);
}
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
void Generator::emit_jump_if(ScopedOperand const& condition, Label true_target, Label false_target)
{
LibJS/Bytecode: Turn `JumpIf true/false` into unconditional `Jump`
2024-05-09 15:16:22 +02:00
if (condition.operand().is_constant()) {
LibJS: Dead code elimination for always truthy/falsey conditions This improves and expands the ability to do dead code elimination on conditions which are always truthy or falsey. The following cases are now optimized: * `if (true){}` -> Only emit `if` block, ignore `else` * `if (false){}` -> Only emit `else if`/`else` block * `while (false){}` -> Ignore `while` loop entirely * `for (x;false;){}` -> Only emit `x` (if it exists), skip `for` block * Ternary -> Directly return left/right hand side if condition is const
2026-01-25 10:57:43 -08:00
auto value = get_constant(condition);
auto is_always_true = value.to_boolean_slow_case();
emit<Op::Jump>(is_always_true ? true_target : false_target);
return;
LibJS/Bytecode: Turn `JumpIf true/false` into unconditional `Jump`
2024-05-09 15:16:22 +02:00
}
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
// NOTE: It's only safe to fuse compare-and-jump if the condition is a temporary with no other dependents.
if (condition.operand().is_register()
&& condition.ref_count() == 1
&& m_current_basic_block->size() > 0) {
if (fuse_compare_and_jump(condition, true_target, false_target))
return;
}
emit<Op::JumpIf>(condition, true_target, false_target);
}
LibJS/Bytecode: Add and use copy_if_needed_to_preserve_evaluation_order This is a new Bytecode::Generator helper that takes an operand and returns the same operand, or a copy of it, in case a copy is required to preserve correct evaluation order. This can be used in a bunch of places where we're worried about clobbering some value after obtaining it. Practically, locals are always copied, and temporary registers as well as constants are returned as-is.
2024-06-01 10:00:32 +02:00
ScopedOperand Generator::copy_if_needed_to_preserve_evaluation_order(ScopedOperand const& operand)
{
if (!operand.operand().is_local())
return operand;
auto new_register = allocate_register();
emit<Bytecode::Op::Mov>(new_register, operand);
return new_register;
}
LibJS/Bytecode: Make constant deduplication a bit smarter Instead of scanning through the list of seen constants, we now have a more structured storage of the constants true, false, null, undefined, and every possible Int32 value. This fixes an O(n^2) issue found by Kraken/json-stringify-tinderbox.js
2024-05-14 14:28:22 +02:00
ScopedOperand Generator::add_constant(Value value)
{
auto append_new_constant = [&] {
m_constants.append(value);
return ScopedOperand { *this, Operand(Operand::Type::Constant, m_constants.size() - 1) };
};
if (value.is_boolean()) {
if (value.as_bool()) {
if (!m_true_constant.has_value())
m_true_constant = append_new_constant();
return m_true_constant.value();
} else {
if (!m_false_constant.has_value())
m_false_constant = append_new_constant();
return m_false_constant.value();
}
}
if (value.is_undefined()) {
if (!m_undefined_constant.has_value())
m_undefined_constant = append_new_constant();
return m_undefined_constant.value();
}
if (value.is_null()) {
if (!m_null_constant.has_value())
m_null_constant = append_new_constant();
return m_null_constant.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 (value.is_special_empty_value()) {
LibJS/Bytecode: Make constant deduplication a bit smarter Instead of scanning through the list of seen constants, we now have a more structured storage of the constants true, false, null, undefined, and every possible Int32 value. This fixes an O(n^2) issue found by Kraken/json-stringify-tinderbox.js
2024-05-14 14:28:22 +02:00
if (!m_empty_constant.has_value())
m_empty_constant = append_new_constant();
return m_empty_constant.value();
}
if (value.is_int32()) {
auto as_int32 = value.as_i32();
return m_int32_constants.ensure(as_int32, [&] {
return append_new_constant();
});
}
LibJS: Cache string constants in Generator::add_constant This mirrors the existing caching logic for int32 constants. Avoids duplication of string constants in m_constants which could result in stack overflows for large scripts with a lot of similar strings.
2025-05-24 15:28:46 +02:00
if (value.is_string()) {
LibJS: Cache bytecode constant strings with their Utf16String as key
2025-10-04 15:52:10 +02:00
auto as_string = value.as_string().utf16_string();
LibJS: Cache string constants in Generator::add_constant This mirrors the existing caching logic for int32 constants. Avoids duplication of string constants in m_constants which could result in stack overflows for large scripts with a lot of similar strings.
2025-05-24 15:28:46 +02:00
return m_string_constants.ensure(as_string, [&] {
return append_new_constant();
});
}
LibJS/Bytecode: Make constant deduplication a bit smarter Instead of scanning through the list of seen constants, we now have a more structured storage of the constants true, false, null, undefined, and every possible Int32 value. This fixes an O(n^2) issue found by Kraken/json-stringify-tinderbox.js
2024-05-14 14:28:22 +02:00
return append_new_constant();
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
void Generator::generate_builtin_abstract_operation(Identifier const& builtin_identifier, ReadonlySpan<CallExpression::Argument> arguments, ScopedOperand const& dst)
LibJS: Introduce NativeJavaScriptBackedFunction This hosts the ability to compile and run JavaScript to implement native functions. This is particularly useful for any native function that is not a normal function, for example async functions such as Array.fromAsync, which require yielding. These functions are not allowed to observe anything from outside their environment. Any global identifiers will instead be assumed to be a reference to an abstract operation or a constant. The generator will inject the appropriate bytecode if the name of the global identifier matches a known name. Anything else will cause a code generation error.
2025-11-06 19:00:36 +00:00
{
VERIFY(m_builtin_abstract_operations_enabled);
LibJS: Convert builtin validation codegen errors to VERIFY These checks validate engine-internal usage of builtin abstract operations (arity, argument types, known operation names), not user JS code. Replace CodeGenerationError returns with VERIFY() assertions: - Spread argument check becomes VERIFY(!argument.is_spread) - Arity checks become VERIFY(arguments.size() == N) - StringLiteral type checks become VERIFY(message) - Unknown operation/constant fallthroughs become VERIFY_NOT_REACHED()
2026-02-11 22:07:14 +01:00
for (auto const& argument : arguments)
VERIFY(!argument.is_spread);
LibJS: Introduce NativeJavaScriptBackedFunction This hosts the ability to compile and run JavaScript to implement native functions. This is particularly useful for any native function that is not a normal function, for example async functions such as Array.fromAsync, which require yielding. These functions are not allowed to observe anything from outside their environment. Any global identifiers will instead be assumed to be a reference to an abstract operation or a constant. The generator will inject the appropriate bytecode if the name of the global identifier matches a known name. Anything else will cause a code generation error.
2025-11-06 19:00:36 +00:00
auto const& operation_name = builtin_identifier.string();
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
if (operation_name == "IsCallable"sv) {
LibJS: Convert builtin validation codegen errors to VERIFY These checks validate engine-internal usage of builtin abstract operations (arity, argument types, known operation names), not user JS code. Replace CodeGenerationError returns with VERIFY() assertions: - Spread argument check becomes VERIFY(!argument.is_spread) - Arity checks become VERIFY(arguments.size() == N) - StringLiteral type checks become VERIFY(message) - Unknown operation/constant fallthroughs become VERIFY_NOT_REACHED()
2026-02-11 22:07:14 +01:00
VERIFY(arguments.size() == 1);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto source = arguments[0].value->generate_bytecode(*this).value();
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
emit<Op::IsCallable>(dst, source);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return;
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
}
if (operation_name == "IsConstructor"sv) {
LibJS: Convert builtin validation codegen errors to VERIFY These checks validate engine-internal usage of builtin abstract operations (arity, argument types, known operation names), not user JS code. Replace CodeGenerationError returns with VERIFY() assertions: - Spread argument check becomes VERIFY(!argument.is_spread) - Arity checks become VERIFY(arguments.size() == N) - StringLiteral type checks become VERIFY(message) - Unknown operation/constant fallthroughs become VERIFY_NOT_REACHED()
2026-02-11 22:07:14 +01:00
VERIFY(arguments.size() == 1);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto source = arguments[0].value->generate_bytecode(*this).value();
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
emit<Op::IsConstructor>(dst, source);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return;
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
}
if (operation_name == "ToBoolean"sv) {
LibJS: Convert builtin validation codegen errors to VERIFY These checks validate engine-internal usage of builtin abstract operations (arity, argument types, known operation names), not user JS code. Replace CodeGenerationError returns with VERIFY() assertions: - Spread argument check becomes VERIFY(!argument.is_spread) - Arity checks become VERIFY(arguments.size() == N) - StringLiteral type checks become VERIFY(message) - Unknown operation/constant fallthroughs become VERIFY_NOT_REACHED()
2026-02-11 22:07:14 +01:00
VERIFY(arguments.size() == 1);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto source = arguments[0].value->generate_bytecode(*this).value();
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
emit<Op::ToBoolean>(dst, source);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return;
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
}
if (operation_name == "ToObject"sv) {
LibJS: Convert builtin validation codegen errors to VERIFY These checks validate engine-internal usage of builtin abstract operations (arity, argument types, known operation names), not user JS code. Replace CodeGenerationError returns with VERIFY() assertions: - Spread argument check becomes VERIFY(!argument.is_spread) - Arity checks become VERIFY(arguments.size() == N) - StringLiteral type checks become VERIFY(message) - Unknown operation/constant fallthroughs become VERIFY_NOT_REACHED()
2026-02-11 22:07:14 +01:00
VERIFY(arguments.size() == 1);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto source = arguments[0].value->generate_bytecode(*this).value();
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
emit<Op::ToObject>(dst, source);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return;
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
}
if (operation_name == "ThrowTypeError"sv) {
LibJS: Convert builtin validation codegen errors to VERIFY These checks validate engine-internal usage of builtin abstract operations (arity, argument types, known operation names), not user JS code. Replace CodeGenerationError returns with VERIFY() assertions: - Spread argument check becomes VERIFY(!argument.is_spread) - Arity checks become VERIFY(arguments.size() == N) - StringLiteral type checks become VERIFY(message) - Unknown operation/constant fallthroughs become VERIFY_NOT_REACHED()
2026-02-11 22:07:14 +01:00
VERIFY(arguments.size() == 1);
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
auto const* message = as_if<StringLiteral>(*arguments[0].value);
LibJS: Convert builtin validation codegen errors to VERIFY These checks validate engine-internal usage of builtin abstract operations (arity, argument types, known operation names), not user JS code. Replace CodeGenerationError returns with VERIFY() assertions: - Spread argument check becomes VERIFY(!argument.is_spread) - Arity checks become VERIFY(arguments.size() == N) - StringLiteral type checks become VERIFY(message) - Unknown operation/constant fallthroughs become VERIFY_NOT_REACHED()
2026-02-11 22:07:14 +01:00
VERIFY(message);
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
auto message_string = intern_string(message->value());
auto type_error_register = allocate_register();
emit<Op::NewTypeError>(type_error_register, message_string);
perform_needed_unwinds<Op::Throw>();
emit<Op::Throw>(type_error_register);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return;
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
}
if (operation_name == "ThrowIfNotObject"sv) {
LibJS: Convert builtin validation codegen errors to VERIFY These checks validate engine-internal usage of builtin abstract operations (arity, argument types, known operation names), not user JS code. Replace CodeGenerationError returns with VERIFY() assertions: - Spread argument check becomes VERIFY(!argument.is_spread) - Arity checks become VERIFY(arguments.size() == N) - StringLiteral type checks become VERIFY(message) - Unknown operation/constant fallthroughs become VERIFY_NOT_REACHED()
2026-02-11 22:07:14 +01:00
VERIFY(arguments.size() == 1);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto source = arguments[0].value->generate_bytecode(*this).value();
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
emit<Op::ThrowIfNotObject>(source);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return;
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
}
if (operation_name == "Call"sv) {
LibJS: Convert builtin validation codegen errors to VERIFY These checks validate engine-internal usage of builtin abstract operations (arity, argument types, known operation names), not user JS code. Replace CodeGenerationError returns with VERIFY() assertions: - Spread argument check becomes VERIFY(!argument.is_spread) - Arity checks become VERIFY(arguments.size() == N) - StringLiteral type checks become VERIFY(message) - Unknown operation/constant fallthroughs become VERIFY_NOT_REACHED()
2026-02-11 22:07:14 +01:00
VERIFY(arguments.size() >= 2);
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
auto const& callee_argument = arguments[0].value;
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto callee = callee_argument->generate_bytecode(*this).value();
auto this_value = arguments[1].value->generate_bytecode(*this).value();
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
auto arguments_to_call_with = arguments.slice(2);
Vector<ScopedOperand> argument_operands;
argument_operands.ensure_capacity(arguments_to_call_with.size());
for (auto const& argument : arguments_to_call_with) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto argument_value = argument.value->generate_bytecode(*this).value();
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
argument_operands.unchecked_append(copy_if_needed_to_preserve_evaluation_order(argument_value));
}
auto expression_string = ([&callee_argument] -> Optional<Utf16String> {
if (auto const* identifier = as_if<Identifier>(*callee_argument))
return identifier->string().to_utf16_string();
if (auto const* member_expression = as_if<MemberExpression>(*callee_argument))
return member_expression->to_string_approximation();
return {};
})();
Optional<Bytecode::StringTableIndex> expression_string_index;
if (expression_string.has_value())
expression_string_index = intern_string(expression_string.release_value());
emit_with_extra_operand_slots<Bytecode::Op::Call>(
argument_operands.size(),
dst,
callee,
this_value,
expression_string_index,
argument_operands);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return;
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
}
if (operation_name == "NewObjectWithNoPrototype"sv) {
LibJS: Convert builtin validation codegen errors to VERIFY These checks validate engine-internal usage of builtin abstract operations (arity, argument types, known operation names), not user JS code. Replace CodeGenerationError returns with VERIFY() assertions: - Spread argument check becomes VERIFY(!argument.is_spread) - Arity checks become VERIFY(arguments.size() == N) - StringLiteral type checks become VERIFY(message) - Unknown operation/constant fallthroughs become VERIFY_NOT_REACHED()
2026-02-11 22:07:14 +01:00
VERIFY(arguments.is_empty());
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
emit<Op::NewObjectWithNoPrototype>(dst);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return;
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
}
if (operation_name == "CreateAsyncFromSyncIterator"sv) {
LibJS: Convert builtin validation codegen errors to VERIFY These checks validate engine-internal usage of builtin abstract operations (arity, argument types, known operation names), not user JS code. Replace CodeGenerationError returns with VERIFY() assertions: - Spread argument check becomes VERIFY(!argument.is_spread) - Arity checks become VERIFY(arguments.size() == N) - StringLiteral type checks become VERIFY(message) - Unknown operation/constant fallthroughs become VERIFY_NOT_REACHED()
2026-02-11 22:07:14 +01:00
VERIFY(arguments.size() == 3);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto iterator = arguments[0].value->generate_bytecode(*this).value();
auto next_method = arguments[1].value->generate_bytecode(*this).value();
auto done = arguments[2].value->generate_bytecode(*this).value();
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
emit<Op::CreateAsyncFromSyncIterator>(dst, iterator, next_method, done);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return;
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
}
if (operation_name == "ToLength"sv) {
LibJS: Convert builtin validation codegen errors to VERIFY These checks validate engine-internal usage of builtin abstract operations (arity, argument types, known operation names), not user JS code. Replace CodeGenerationError returns with VERIFY() assertions: - Spread argument check becomes VERIFY(!argument.is_spread) - Arity checks become VERIFY(arguments.size() == N) - StringLiteral type checks become VERIFY(message) - Unknown operation/constant fallthroughs become VERIFY_NOT_REACHED()
2026-02-11 22:07:14 +01:00
VERIFY(arguments.size() == 1);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto value = arguments[0].value->generate_bytecode(*this).value();
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
emit<Op::ToLength>(dst, value);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return;
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
}
if (operation_name == "NewTypeError"sv) {
LibJS: Convert builtin validation codegen errors to VERIFY These checks validate engine-internal usage of builtin abstract operations (arity, argument types, known operation names), not user JS code. Replace CodeGenerationError returns with VERIFY() assertions: - Spread argument check becomes VERIFY(!argument.is_spread) - Arity checks become VERIFY(arguments.size() == N) - StringLiteral type checks become VERIFY(message) - Unknown operation/constant fallthroughs become VERIFY_NOT_REACHED()
2026-02-11 22:07:14 +01:00
VERIFY(arguments.size() == 1);
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
auto const* message = as_if<StringLiteral>(*arguments[0].value);
LibJS: Convert builtin validation codegen errors to VERIFY These checks validate engine-internal usage of builtin abstract operations (arity, argument types, known operation names), not user JS code. Replace CodeGenerationError returns with VERIFY() assertions: - Spread argument check becomes VERIFY(!argument.is_spread) - Arity checks become VERIFY(arguments.size() == N) - StringLiteral type checks become VERIFY(message) - Unknown operation/constant fallthroughs become VERIFY_NOT_REACHED()
2026-02-11 22:07:14 +01:00
VERIFY(message);
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
auto message_string = intern_string(message->value());
emit<Op::NewTypeError>(dst, message_string);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return;
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
}
if (operation_name == "NewArrayWithLength"sv) {
LibJS: Convert builtin validation codegen errors to VERIFY These checks validate engine-internal usage of builtin abstract operations (arity, argument types, known operation names), not user JS code. Replace CodeGenerationError returns with VERIFY() assertions: - Spread argument check becomes VERIFY(!argument.is_spread) - Arity checks become VERIFY(arguments.size() == N) - StringLiteral type checks become VERIFY(message) - Unknown operation/constant fallthroughs become VERIFY_NOT_REACHED()
2026-02-11 22:07:14 +01:00
VERIFY(arguments.size() == 1);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto length = arguments[0].value->generate_bytecode(*this).value();
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
emit<Op::NewArrayWithLength>(dst, length);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return;
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
}
if (operation_name == "CreateDataPropertyOrThrow"sv) {
LibJS: Convert builtin validation codegen errors to VERIFY These checks validate engine-internal usage of builtin abstract operations (arity, argument types, known operation names), not user JS code. Replace CodeGenerationError returns with VERIFY() assertions: - Spread argument check becomes VERIFY(!argument.is_spread) - Arity checks become VERIFY(arguments.size() == N) - StringLiteral type checks become VERIFY(message) - Unknown operation/constant fallthroughs become VERIFY_NOT_REACHED()
2026-02-11 22:07:14 +01:00
VERIFY(arguments.size() == 3);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto object = arguments[0].value->generate_bytecode(*this).value();
auto property = arguments[1].value->generate_bytecode(*this).value();
auto value = arguments[2].value->generate_bytecode(*this).value();
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
emit<Op::CreateDataPropertyOrThrow>(object, property, value);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return;
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
}
#define __JS_ENUMERATE(snake_name, functionName, length) \
if (operation_name == #functionName##sv) { \
Vector<ScopedOperand> argument_operands; \
argument_operands.ensure_capacity(arguments.size()); \
for (auto const& argument : arguments) { \
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto argument_value = argument.value->generate_bytecode(*this).value(); \
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
argument_operands.unchecked_append(copy_if_needed_to_preserve_evaluation_order(argument_value)); \
} \
emit_with_extra_operand_slots<Bytecode::Op::Call>( \
argument_operands.size(), \
dst, \
add_constant(m_vm.current_realm()->intrinsics().snake_name##_abstract_operation_function()), \
add_constant(js_undefined()), \
intern_string(builtin_identifier.string().to_utf16_string()), \
argument_operands); \
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return; \
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
}
JS_ENUMERATE_NATIVE_JAVASCRIPT_BACKED_ABSTRACT_OPERATIONS
#undef __JS_ENUMERATE
LibJS: Convert builtin validation codegen errors to VERIFY These checks validate engine-internal usage of builtin abstract operations (arity, argument types, known operation names), not user JS code. Replace CodeGenerationError returns with VERIFY() assertions: - Spread argument check becomes VERIFY(!argument.is_spread) - Arity checks become VERIFY(arguments.size() == N) - StringLiteral type checks become VERIFY(message) - Unknown operation/constant fallthroughs become VERIFY_NOT_REACHED()
2026-02-11 22:07:14 +01:00
VERIFY_NOT_REACHED();
LibJS: Introduce NativeJavaScriptBackedFunction This hosts the ability to compile and run JavaScript to implement native functions. This is particularly useful for any native function that is not a normal function, for example async functions such as Array.fromAsync, which require yielding. These functions are not allowed to observe anything from outside their environment. Any global identifiers will instead be assumed to be a reference to an abstract operation or a constant. The generator will inject the appropriate bytecode if the name of the global identifier matches a known name. Anything else will cause a code generation error.
2025-11-06 19:00:36 +00:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> Generator::maybe_generate_builtin_constant(Identifier const& builtin_identifier)
LibJS: Introduce NativeJavaScriptBackedFunction This hosts the ability to compile and run JavaScript to implement native functions. This is particularly useful for any native function that is not a normal function, for example async functions such as Array.fromAsync, which require yielding. These functions are not allowed to observe anything from outside their environment. Any global identifiers will instead be assumed to be a reference to an abstract operation or a constant. The generator will inject the appropriate bytecode if the name of the global identifier matches a known name. Anything else will cause a code generation error.
2025-11-06 19:00:36 +00:00
{
auto const& constant_name = builtin_identifier.string();
if (constant_name == "undefined"sv) {
return add_constant(js_undefined());
}
LibJS: Constant fold `LogicalExpression` Logical expressions like `true || false` are now constant folded. This also allows for dead code elimination if we know the right-hand side of the expression will never be evaluated (such as `false && f()` or `true || f()`). In the test suites, the values are now being constant folded at compile time. To ensure that the actual evaluation logic is being called properly, I had to duplicate the tests and call them via a function so the compiler would not optimize the evaluation logic away. This also demotes `NaN` and `Infinity` identifiers to `nan` and `inf` double literals, which will further help with const folding.
2026-01-11 12:36:23 -08:00
if (constant_name == "NaN"sv) {
return add_constant(js_nan());
}
if (constant_name == "Infinity"sv) {
return add_constant(js_infinity());
}
LibJS: Introduce NativeJavaScriptBackedFunction This hosts the ability to compile and run JavaScript to implement native functions. This is particularly useful for any native function that is not a normal function, for example async functions such as Array.fromAsync, which require yielding. These functions are not allowed to observe anything from outside their environment. Any global identifiers will instead be assumed to be a reference to an abstract operation or a constant. The generator will inject the appropriate bytecode if the name of the global identifier matches a known name. Anything else will cause a code generation error.
2025-11-06 19:00:36 +00:00
if (!m_builtin_abstract_operations_enabled)
return OptionalNone {};
LibJS: Replace Array.fromAsync with a native JavaScript implementation This allows us to use the bytecode implementation of await, which correctly suspends execution contexts and handles completion injections. This gains us 4 test262 tests around mutating Array.fromAsync's iterable whilst it's suspended as well. This is also one step towards removing spin_until, which the non-bytecode implementation of await uses. ``` Duration: -5.98s Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: [...]/Array/fromAsync/asyncitems-array-add-to-singleton.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-add.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-mutate.js ❌ -> ✅ [...]/Array/fromAsync/asyncitems-array-remove.js ❌ -> ✅ ```
2025-11-06 19:20:29 +00:00
if (constant_name == "SYMBOL_ITERATOR"sv) {
return add_constant(vm().well_known_symbol_iterator());
}
if (constant_name == "SYMBOL_ASYNC_ITERATOR"sv) {
return add_constant(vm().well_known_symbol_async_iterator());
}
if (constant_name == "MAX_ARRAY_LIKE_INDEX"sv) {
return add_constant(Value(MAX_ARRAY_LIKE_INDEX));
}
LibJS: Convert builtin validation codegen errors to VERIFY These checks validate engine-internal usage of builtin abstract operations (arity, argument types, known operation names), not user JS code. Replace CodeGenerationError returns with VERIFY() assertions: - Spread argument check becomes VERIFY(!argument.is_spread) - Arity checks become VERIFY(arguments.size() == N) - StringLiteral type checks become VERIFY(message) - Unknown operation/constant fallthroughs become VERIFY_NOT_REACHED()
2026-02-11 22:07:14 +01:00
VERIFY_NOT_REACHED();
LibJS: Introduce NativeJavaScriptBackedFunction This hosts the ability to compile and run JavaScript to implement native functions. This is particularly useful for any native function that is not a normal function, for example async functions such as Array.fromAsync, which require yielding. These functions are not allowed to observe anything from outside their environment. Any global identifiers will instead be assumed to be a reference to an abstract operation or a constant. The generator will inject the appropriate bytecode if the name of the global identifier matches a known name. Anything else will cause a code generation error.
2025-11-06 19:00:36 +00:00
}
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
}
Reference in a new issue Copy permalink