Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-31 13:20:59 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibJS/Bytecode/Generator.h

418 lines
16 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
/*
Meta: Update my e-mail address everywhere
2024-10-04 13:19:50 +02:00
* Copyright (c) 2021-2024, 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
*/
#pragma once
#include <AK/OwnPtr.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 <AK/SinglyLinkedList.h>
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
#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: 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
#include <LibJS/Bytecode/CodeGenerationError.h>
LibJS: Add Bytecode::Executable::dump() Let's have a helper for producing a consistent executable dump instead of repeating the logic in multiple places.
2021-10-24 13:30:49 +02:00
#include <LibJS/Bytecode/Executable.h>
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
#include <LibJS/Bytecode/IdentifierTable.h>
LibJS: Add basic support for while loops in the bytecode engine This introduces two new instructions: Jump and JumpIfFalse. Jumps are made to a Bytecode::Label, which is a simple object that represents a location in the bytecode stream. Note that you may not always know the target of a jump when adding the jump instruction itself, but we can just update the instruction later on during codegen once we know where the jump target is. The Bytecode::Interpreter now implements jumping via a jump slot that gets checked after each instruction to see if a jump is pending. If not, we just increment the PC as usual.
2021-06-04 12:07:38 +02:00
#include <LibJS/Bytecode/Label.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>
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
#include <LibJS/Bytecode/Register.h>
LibJS: Store strings in a string table Instead of using Strings in the bytecode ops this adds a global string table to the Executable struct which individual operations can refer to using indices. This brings bytecode ops one step closer to being pointer free.
2021-06-09 10:02:01 +02:00
#include <LibJS/Bytecode/StringTable.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/Forward.h>
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
#include <LibJS/Runtime/FunctionKind.h>
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
#include <LibRegex/Regex.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 {
class Generator {
public:
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
VM& vm() { return m_vm; }
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 19:48:45 +03:30
enum class SurroundingScopeKind {
Global,
Function,
Block,
};
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: 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
enum class MustPropagateCompletion {
No,
Yes,
};
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
static CodeGenerationErrorOr<GC::Ref<Executable>> generate_from_ast_node(VM&, ASTNode const&, FunctionKind = FunctionKind::Normal);
static CodeGenerationErrorOr<GC::Ref<Executable>> generate_from_function(VM&, ECMAScriptFunctionObject const& function);
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
CodeGenerationErrorOr<void> emit_function_declaration_instantiation(ECMAScriptFunctionObject const& function);
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: 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
[[nodiscard]] ScopedOperand allocate_register();
[[nodiscard]] ScopedOperand local(u32 local_index);
[[nodiscard]] ScopedOperand 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
[[nodiscard]] ScopedOperand 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
void free_register(Register);
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: 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
void set_local_initialized(u32 local_index);
[[nodiscard]] bool is_local_initialized(u32 local_index) const;
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
class SourceLocationScope {
public:
SourceLocationScope(Generator&, ASTNode const& node);
~SourceLocationScope();
private:
Generator& m_generator;
ASTNode const* m_previous_node { nullptr };
};
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
class UnwindContext {
public:
UnwindContext(Generator&, Optional<Label> finalizer);
UnwindContext const* previous() const { return m_previous_context; }
void set_handler(Label handler) { m_handler = handler; }
Optional<Label> handler() const { return m_handler; }
Optional<Label> finalizer() const { return m_finalizer; }
~UnwindContext();
private:
Generator& m_generator;
Optional<Label> m_finalizer;
Optional<Label> m_handler {};
UnwindContext const* m_previous_context { nullptr };
};
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
template<typename OpType, typename... Args>
LibJS: Fail compilation earlier when trying to emit with wrong arguments This makes the compilation backtraces a lot nicer, and allows clangd to see the mistake as well.
2024-05-06 23:00:19 +02:00
requires(requires { OpType(declval<Args>()...); })
LibJS: Make Bytecode::Generator::emit() return void There are no callers left that use the return value.
2023-09-28 12:48:29 +02:00
void emit(Args&&... args)
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 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(!is_current_block_terminated());
LibJS: Use a Vector<u8> for BasicBlock instruction storage This reduces the minimum size of a basic block from 4 KiB to 0 bytes. With this change, memory usage at the end of Speedometer is 1.2 GiB, down from 1.8 GiB.
2023-09-28 09:29:42 +02:00
size_t slot_offset = m_current_basic_block->size();
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
m_current_basic_block->set_last_instruction_start_offset(slot_offset);
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
grow(sizeof(OpType));
LibJS: Use a Vector<u8> for BasicBlock instruction storage This reduces the minimum size of a basic block from 4 KiB to 0 bytes. With this change, memory usage at the end of Speedometer is 1.2 GiB, down from 1.8 GiB.
2023-09-28 09:29:42 +02:00
void* slot = m_current_basic_block->data() + slot_offset;
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
new (slot) OpType(forward<Args>(args)...);
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
if constexpr (OpType::IsTerminator)
Revert "LibJS/Bytecode: Bring back the bytecode optimization pipeline" This reverts commit 5b29974bfa9b14224c5a1dc4feb41e22eda1e0f2.
2024-03-06 08:36:19 +01:00
m_current_basic_block->terminate({});
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
m_current_basic_block->add_source_map_entry(slot_offset, { m_current_ast_node->start_offset(), m_current_ast_node->end_offset() });
LibJS: Devirtualize and pack the bytecode stream :^) This patch changes the LibJS bytecode to be a stream of instructions packed one-after-the-other in contiguous memory, instead of a vector of OwnPtr<Instruction>. This should be a lot more cache-friendly. :^) Instructions are also devirtualized and instead have a type field using a new Instruction::Type enum. To iterate over a bytecode stream, one must now use Bytecode::InstructionStreamIterator.
2021-06-07 15:12:43 +02:00
}
LibJS/Bytecode: Make NewPrimitiveArray a variable-length instruction Instead of having a FixedArray with a separate heap allocation, we can just bake the primitive values into the instruction itself.
2024-03-03 12:37:28 +01:00
template<typename OpType, typename ExtraSlotType, typename... Args>
LibJS: Fail compilation earlier when trying to emit with wrong arguments This makes the compilation backtraces a lot nicer, and allows clangd to see the mistake as well.
2024-05-06 23:00:19 +02:00
requires(requires { OpType(declval<Args>()...); })
LibJS/Bytecode: Make NewPrimitiveArray a variable-length instruction Instead of having a FixedArray with a separate heap allocation, we can just bake the primitive values into the instruction itself.
2024-03-03 12:37:28 +01:00
void emit_with_extra_slots(size_t extra_slot_count, Args&&... args)
LibJS: Devirtualize and pack the bytecode stream :^) This patch changes the LibJS bytecode to be a stream of instructions packed one-after-the-other in contiguous memory, instead of a vector of OwnPtr<Instruction>. This should be a lot more cache-friendly. :^) Instructions are also devirtualized and instead have a type field using a new Instruction::Type enum. To iterate over a bytecode stream, one must now use Bytecode::InstructionStreamIterator.
2021-06-07 15:12:43 +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
VERIFY(!is_current_block_terminated());
LibJS: Align Instructions as void* and roundup variably sized ones sizes Both is indeed needed, the standard alignment would have been 4, but some Instructions, like Jumps need an alignment of 8 Fixes #12127.
2022-09-09 16:47:42 +02:00
LibJS/Bytecode: Make NewPrimitiveArray a variable-length instruction Instead of having a FixedArray with a separate heap allocation, we can just bake the primitive values into the instruction itself.
2024-03-03 12:37:28 +01:00
size_t size_to_allocate = round_up_to_power_of_two(sizeof(OpType) + extra_slot_count * sizeof(ExtraSlotType), alignof(void*));
LibJS: Use a Vector<u8> for BasicBlock instruction storage This reduces the minimum size of a basic block from 4 KiB to 0 bytes. With this change, memory usage at the end of Speedometer is 1.2 GiB, down from 1.8 GiB.
2023-09-28 09:29:42 +02:00
size_t slot_offset = m_current_basic_block->size();
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
m_current_basic_block->set_last_instruction_start_offset(slot_offset);
LibJS: Align Instructions as void* and roundup variably sized ones sizes Both is indeed needed, the standard alignment would have been 4, but some Instructions, like Jumps need an alignment of 8 Fixes #12127.
2022-09-09 16:47:42 +02:00
grow(size_to_allocate);
LibJS: Use a Vector<u8> for BasicBlock instruction storage This reduces the minimum size of a basic block from 4 KiB to 0 bytes. With this change, memory usage at the end of Speedometer is 1.2 GiB, down from 1.8 GiB.
2023-09-28 09:29:42 +02:00
void* slot = m_current_basic_block->data() + slot_offset;
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
new (slot) OpType(forward<Args>(args)...);
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
if constexpr (OpType::IsTerminator)
Revert "LibJS/Bytecode: Bring back the bytecode optimization pipeline" This reverts commit 5b29974bfa9b14224c5a1dc4feb41e22eda1e0f2.
2024-03-06 08:36:19 +01:00
m_current_basic_block->terminate({});
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
m_current_basic_block->add_source_map_entry(slot_offset, { m_current_ast_node->start_offset(), m_current_ast_node->end_offset() });
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 NewPrimitiveArray a variable-length instruction Instead of having a FixedArray with a separate heap allocation, we can just bake the primitive values into the instruction itself.
2024-03-03 12:37:28 +01:00
template<typename OpType, typename... Args>
LibJS: Fail compilation earlier when trying to emit with wrong arguments This makes the compilation backtraces a lot nicer, and allows clangd to see the mistake as well.
2024-05-06 23:00:19 +02:00
requires(requires { OpType(declval<Args>()...); })
LibJS/Bytecode: Make NewPrimitiveArray a variable-length instruction Instead of having a FixedArray with a separate heap allocation, we can just bake the primitive values into the instruction itself.
2024-03-03 12:37:28 +01:00
void emit_with_extra_operand_slots(size_t extra_operand_slots, Args&&... args)
{
emit_with_extra_slots<OpType, Operand>(extra_operand_slots, forward<Args>(args)...);
}
template<typename OpType, typename... Args>
LibJS: Fail compilation earlier when trying to emit with wrong arguments This makes the compilation backtraces a lot nicer, and allows clangd to see the mistake as well.
2024-05-06 23:00:19 +02:00
requires(requires { OpType(declval<Args>()...); })
LibJS/Bytecode: Make NewPrimitiveArray a variable-length instruction Instead of having a FixedArray with a separate heap allocation, we can just bake the primitive values into the instruction itself.
2024-03-03 12:37:28 +01:00
void emit_with_extra_value_slots(size_t extra_operand_slots, Args&&... args)
{
emit_with_extra_slots<OpType, Value>(extra_operand_slots, forward<Args>(args)...);
}
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
void emit_mov(ScopedOperand const& dst, ScopedOperand const& src)
{
// Optimize away when the source is the destination
if (dst != src)
emit<Op::Mov>(dst, src);
}
void emit_mov(Operand const& dst, Operand const& src)
{
emit<Op::Mov>(dst, src);
}
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 emit_jump_if(ScopedOperand const& condition, Label true_target, Label false_target);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
struct ReferenceOperands {
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> base {}; // [[Base]]
Optional<ScopedOperand> referenced_name {}; // [[ReferencedName]] as an operand
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
Optional<IdentifierTableIndex> referenced_identifier {}; // [[ReferencedName]] as an identifier
Optional<IdentifierTableIndex> referenced_private_identifier {}; // [[ReferencedName]] as a private identifier
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> this_value {}; // [[ThisValue]]
Optional<ScopedOperand> loaded_value {}; // Loaded value, if we've performed a load.
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: 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
CodeGenerationErrorOr<ReferenceOperands> emit_load_from_reference(JS::ASTNode const&, Optional<ScopedOperand> preferred_dst = {});
CodeGenerationErrorOr<void> emit_store_to_reference(JS::ASTNode const&, ScopedOperand value);
CodeGenerationErrorOr<void> emit_store_to_reference(ReferenceOperands const&, ScopedOperand value);
CodeGenerationErrorOr<Optional<ScopedOperand>> emit_delete_reference(JS::ASTNode const&);
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
CodeGenerationErrorOr<ReferenceOperands> emit_super_reference(MemberExpression const&);
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: 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 emit_set_variable(JS::Identifier const& identifier, ScopedOperand value, Bytecode::Op::BindingInitializationMode initialization_mode = Bytecode::Op::BindingInitializationMode::Set, Bytecode::Op::EnvironmentMode mode = Bytecode::Op::EnvironmentMode::Lexical);
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/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 push_home_object(ScopedOperand);
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 pop_home_object();
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 emit_new_function(ScopedOperand dst, JS::FunctionExpression const&, Optional<IdentifierTableIndex> lhs_name);
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/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
CodeGenerationErrorOr<Optional<ScopedOperand>> emit_named_evaluation_if_anonymous_function(Expression const&, Optional<IdentifierTableIndex> lhs_name, Optional<ScopedOperand> preferred_dst = {});
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: Use FlyString in PropertyKey instead of DeprecatedFlyString This required dealing with *substantial* fallout.
2025-03-18 18:08:02 -05:00
void begin_continuable_scope(Label continue_target, Vector<FlyString> const& language_label_set);
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 end_continuable_scope();
LibJS: Use FlyString in PropertyKey instead of DeprecatedFlyString This required dealing with *substantial* fallout.
2025-03-18 18:08:02 -05:00
void begin_breakable_scope(Label breakable_target, Vector<FlyString> const& language_label_set);
LibJS: Implement bytecode generation for BreakStatement
2021-06-10 20:28:43 +08:00
void end_breakable_scope();
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: 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
[[nodiscard]] Label nearest_continuable_scope() const;
LibJS: Implement bytecode generation for BreakStatement
2021-06-10 20:28:43 +08:00
[[nodiscard]] Label nearest_breakable_scope() const;
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
void switch_to_basic_block(BasicBlock& block)
{
m_current_basic_block = &block;
}
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
[[nodiscard]] BasicBlock& current_block() { return *m_current_basic_block; }
LibJS: Migrate DeprecatedString to String This changes BasicBlock's constructor and create().
2023-10-26 23:57:51 -04:00
BasicBlock& make_block(String name = {})
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
{
if (name.is_empty())
AK: Make String::number() infallible This API will always succeed in creating a String representing the provided number in base-10.
2024-10-14 10:05:01 +02:00
name = String::number(m_next_block++);
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 = BasicBlock::create(m_root_basic_blocks.size(), name);
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
if (auto const* context = m_current_unwind_context) {
if (context->handler().has_value())
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
block->set_handler(*m_root_basic_blocks[context->handler().value().basic_block_index()]);
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
if (m_current_unwind_context->finalizer().has_value())
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
block->set_finalizer(*m_root_basic_blocks[context->finalizer().value().basic_block_index()]);
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_root_basic_blocks.append(move(block));
Everywhere: Stop using NonnullOwnPtrVector Same as NonnullRefPtrVector: weird semantics, questionable benefits.
2023-03-06 17:16:25 +01:00
return *m_root_basic_blocks.last();
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
}
bool is_current_block_terminated() const
{
return m_current_basic_block->is_terminated();
}
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: Use FlyString in PropertyKey instead of DeprecatedFlyString This required dealing with *substantial* fallout.
2025-03-18 18:08:02 -05:00
StringTableIndex intern_string(String string)
LibJS: Store strings in a string table Instead of using Strings in the bytecode ops this adds a global string table to the Executable struct which individual operations can refer to using indices. This brings bytecode ops one step closer to being pointer free.
2021-06-09 10:02:01 +02:00
{
LibJS: Use String and move semantics in Bytecode::StringTable Avoid creating new AK::String objects when we already have one.
2021-10-24 15:14:14 +02:00
return m_string_table->insert(move(string));
LibJS: Store strings in a string table Instead of using Strings in the bytecode ops this adds a global string table to the Executable struct which individual operations can refer to using indices. This brings bytecode ops one step closer to being pointer free.
2021-06-09 10:02:01 +02:00
}
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
RegexTableIndex intern_regex(ParsedRegex regex)
{
return m_regex_table->insert(move(regex));
}
LibJS: Use FlyString in PropertyKey instead of DeprecatedFlyString This required dealing with *substantial* fallout.
2025-03-18 18:08:02 -05:00
IdentifierTableIndex intern_identifier(FlyString string)
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
{
return m_identifier_table->insert(move(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
Optional<IdentifierTableIndex> intern_identifier_for_expression(Expression const& expression);
LibJS/Bytecode: Class async generators as async functions
2023-07-14 21:44:36 +01:00
bool is_in_generator_or_async_function() const { return m_enclosing_function_kind == FunctionKind::Async || m_enclosing_function_kind == FunctionKind::Generator || m_enclosing_function_kind == FunctionKind::AsyncGenerator; }
bool is_in_generator_function() const { return m_enclosing_function_kind == FunctionKind::Generator || m_enclosing_function_kind == FunctionKind::AsyncGenerator; }
bool is_in_async_function() const { return m_enclosing_function_kind == FunctionKind::Async || m_enclosing_function_kind == FunctionKind::AsyncGenerator; }
LibJS/Bytecode: Add function to determine if we're in an async generator
2023-07-14 21:45:41 +01:00
bool is_in_async_generator_function() const { return m_enclosing_function_kind == FunctionKind::AsyncGenerator; }
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 19:48:45 +03:30
enum class BindingMode {
Lexical,
Var,
Global,
};
struct LexicalScope {
SurroundingScopeKind kind;
};
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
// Returns true if a lexical environment was created.
bool emit_block_declaration_instantiation(ScopeNode const&);
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: 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 begin_variable_scope();
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 end_variable_scope();
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 19:48:45 +03:30
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
enum class BlockBoundaryType {
Break,
Continue,
Unwind,
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
ReturnToFinally,
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
LeaveFinally,
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
LeaveLexicalEnvironment,
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
};
template<typename OpType>
LibJS: Simplify `Generator::perform_needed_unwinds` This does not need to cater to the needs of `break` and `continue anymore, which allows us to simplify it a bit.
2022-11-25 16:42:29 +01:00
void perform_needed_unwinds()
requires(OpType::IsTerminator && !IsSame<OpType, Op::Jump>)
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
{
for (size_t i = m_boundaries.size(); i > 0; --i) {
auto boundary = m_boundaries[i - 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
using enum BlockBoundaryType;
switch (boundary) {
case Unwind:
LibJS: Simplify `Generator::perform_needed_unwinds` This does not need to cater to the needs of `break` and `continue anymore, which allows us to simplify it a bit.
2022-11-25 16:42:29 +01:00
if constexpr (IsSame<OpType, Bytecode::Op::Throw>)
return;
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
emit<Bytecode::Op::LeaveUnwindContext>();
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
break;
case LeaveLexicalEnvironment:
LibJS/Bytecode: Simplify creating/leaving lexical environment Since we no longer need to create or leave var environments directly in bytecode, we can streamline the two instructions by making them always operate on the lexical environment.
2023-06-16 16:43:24 +02:00
emit<Bytecode::Op::LeaveLexicalEnvironment>();
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
break;
case Break:
case Continue:
break;
case ReturnToFinally:
return;
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:
emit<Bytecode::Op::LeaveFinally>();
break;
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
};
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
}
}
LibJS: Save and restore exceptions on yields in finalizers Also removes a bunch of related old FIXMEs.
2024-05-06 22:38:43 +02:00
bool is_in_finalizer() const { return m_boundaries.contains_slow(BlockBoundaryType::LeaveFinally); }
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
bool must_enter_finalizer() const { return m_boundaries.contains_slow(BlockBoundaryType::ReturnToFinally); }
LibJS: Save and restore exceptions on yields in finalizers Also removes a bunch of related old FIXMEs.
2024-05-06 22:38:43 +02:00
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
void generate_break();
LibJS: Use FlyString in PropertyKey instead of DeprecatedFlyString This required dealing with *substantial* fallout.
2025-03-18 18:08:02 -05:00
void generate_break(FlyString const& break_label);
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: 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 generate_continue();
LibJS: Use FlyString in PropertyKey instead of DeprecatedFlyString This required dealing with *substantial* fallout.
2025-03-18 18:08:02 -05:00
void 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: 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
template<typename OpType>
void emit_return(ScopedOperand value)
requires(IsOneOf<OpType, Op::Return, Op::Yield>)
{
perform_needed_unwinds<OpType>();
if (must_enter_finalizer()) {
VERIFY(m_current_basic_block->finalizer() != nullptr);
// Compare to:
// * Interpreter::do_return
// * Interpreter::run_bytecode::handle_ContinuePendingUnwind
// * Return::execute_impl
// * Yield::execute_impl
LibJS: Prepare yield object before re-routing it through finally
2024-05-18 17:25:43 +02:00
if constexpr (IsSame<OpType, Op::Yield>)
emit<Bytecode::Op::PrepareYield>(Operand(Register::saved_return_value()), value);
else
emit<Bytecode::Op::Mov>(Operand(Register::saved_return_value()), value);
LibJS: Make return control flow more static With this only `ContinuePendingUnwind` needs to dynamically check if a scheduled return needs to go through a `finally` block, making the interpreter loop a bit nicer
2024-05-12 11:03:26 +02:00
emit<Bytecode::Op::Mov>(Operand(Register::exception()), add_constant(Value {}));
emit<Bytecode::Op::Jump>(Label { *m_current_basic_block->finalizer() });
return;
}
if constexpr (IsSame<OpType, Op::Return>)
emit<Op::Return>(value);
else
emit<Op::Yield>(nullptr, value);
}
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
void start_boundary(BlockBoundaryType type) { m_boundaries.append(type); }
void end_boundary(BlockBoundaryType type)
{
VERIFY(m_boundaries.last() == type);
m_boundaries.take_last();
}
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
[[nodiscard]] ScopedOperand copy_if_needed_to_preserve_evaluation_order(ScopedOperand const&);
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
[[nodiscard]] ScopedOperand 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: 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 emit_get_by_id(ScopedOperand dst, ScopedOperand base, IdentifierTableIndex property_identifier, 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/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 emit_get_by_id_with_this(ScopedOperand dst, ScopedOperand base, IdentifierTableIndex, ScopedOperand this_value);
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 emit_iterator_value(ScopedOperand dst, ScopedOperand result);
void emit_iterator_complete(ScopedOperand dst, ScopedOperand result);
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: Add optimized GetGlobal instruction to access global variables Using a special instruction to access global variables allows skipping the environment chain traversal for them and going directly to the module/global environment. Currently, this instruction only caches the offset for bindings that belong to the global object environment. However, there is also an opportunity to cache the offset in the global declarative record. This change results in a 57% increase in speed for imaging-gaussian-blur.js in Kraken.
2023-07-12 04:06:59 +02:00
[[nodiscard]] size_t next_global_variable_cache() { return m_next_global_variable_cache++; }
LibJS: Add basic monomorphic caching for PutById property access This patch makes it possible for JS::Object::internal_set() to populate a CacheablePropertyMetadata, and uses this to implement a basic monomorphic cache for the most common form of property write access.
2023-11-08 20:51:26 +01:00
[[nodiscard]] size_t next_property_lookup_cache() { return m_next_property_lookup_cache++; }
LibJS: Add optimized GetGlobal instruction to access global variables Using a special instruction to access global variables allows skipping the environment chain traversal for them and going directly to the module/global environment. Currently, this instruction only caches the offset for bindings that belong to the global object environment. However, there is also an opportunity to cache the offset in the global declarative record. This change results in a 57% increase in speed for imaging-gaussian-blur.js in Kraken.
2023-07-12 04:06:59 +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
enum class DeduplicateConstant {
Yes,
No,
};
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
[[nodiscard]] ScopedOperand add_constant(Value);
LibJS/Bytecode: Add constants table to Bytecode::Executable
2024-02-02 09:52:25 +01:00
LibJS/Bytecode: Perform constant folding on binary expressions This turns expressions like `(2 + 3) * 8 / 2` into a constant (20) at bytecode compilation time instead of generating instructions to calculate the value.
2024-05-31 21:49:46 +02:00
[[nodiscard]] Value get_constant(ScopedOperand const& operand) const
{
VERIFY(operand.operand().is_constant());
return m_constants[operand.operand().index()];
}
LibJS: Propagate finalizers into nested try-catch blocks without them
2024-04-11 00:25:54 +02:00
UnwindContext const* current_unwind_context() const { return m_current_unwind_context; }
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
[[nodiscard]] bool is_finished() const { return m_finished; }
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
[[nodiscard]] bool must_propagate_completion() const { return m_must_propagate_completion; }
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
private:
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
VM& m_vm;
LibJS: Use FlyString in PropertyKey instead of DeprecatedFlyString This required dealing with *substantial* fallout.
2025-03-18 18:08:02 -05:00
static CodeGenerationErrorOr<GC::Ref<Executable>> compile(VM&, ASTNode const&, FunctionKind, GC::Ptr<ECMAScriptFunctionObject const>, MustPropagateCompletion, Vector<FlyString> 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: 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
enum class JumpType {
Continue,
Break,
};
void generate_scoped_jump(JumpType);
LibJS: Use FlyString in PropertyKey instead of DeprecatedFlyString This required dealing with *substantial* fallout.
2025-03-18 18:08:02 -05:00
void generate_labelled_jump(JumpType, FlyString const& label);
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
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
Generator(VM&, GC::Ptr<ECMAScriptFunctionObject const>, MustPropagateCompletion);
Libraries: Use default constructors/destructors in LibJS https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 10:25:06 -06:00
~Generator() = default;
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
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 grow(size_t);
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: 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
// Returns true if a fused instruction was emitted.
[[nodiscard]] bool fuse_compare_and_jump(ScopedOperand const& condition, Label true_target, Label false_target);
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
struct LabelableScope {
Label bytecode_target;
LibJS: Use FlyString in PropertyKey instead of DeprecatedFlyString This required dealing with *substantial* fallout.
2025-03-18 18:08:02 -05:00
Vector<FlyString> language_label_set;
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: 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
BasicBlock* m_current_basic_block { nullptr };
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
ASTNode const* m_current_ast_node { nullptr };
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
UnwindContext const* m_current_unwind_context { nullptr };
Everywhere: Stop using NonnullOwnPtrVector Same as NonnullRefPtrVector: weird semantics, questionable benefits.
2023-03-06 17:16:25 +01:00
Vector<NonnullOwnPtr<BasicBlock>> m_root_basic_blocks;
LibJS: Store strings in a string table Instead of using Strings in the bytecode ops this adds a global string table to the Executable struct which individual operations can refer to using indices. This brings bytecode ops one step closer to being pointer free.
2021-06-09 10:02:01 +02:00
NonnullOwnPtr<StringTable> m_string_table;
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
NonnullOwnPtr<IdentifierTable> m_identifier_table;
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
NonnullOwnPtr<RegexTable> m_regex_table;
LibGC: Rename MarkedVector => RootVector Let's try to make it a bit more clear that this is a Vector of GC roots.
2024-12-26 14:32:52 +01:00
GC::RootVector<Value> m_constants;
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
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
mutable Optional<ScopedOperand> m_true_constant;
mutable Optional<ScopedOperand> m_false_constant;
mutable Optional<ScopedOperand> m_null_constant;
mutable Optional<ScopedOperand> m_undefined_constant;
mutable Optional<ScopedOperand> m_empty_constant;
mutable HashMap<i32, ScopedOperand> m_int32_constants;
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 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 m_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
Vector<Register> m_free_registers;
LibJS: Keep cached `this` value in a call frame register Just moving more things to call frame registers..
2023-09-26 14:42:30 +02:00
u32 m_next_register { Register::reserved_register_count };
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
u32 m_next_block { 1 };
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
u32 m_next_property_lookup_cache { 0 };
LibJS: Add optimized GetGlobal instruction to access global variables Using a special instruction to access global variables allows skipping the environment chain traversal for them and going directly to the module/global environment. Currently, this instruction only caches the offset for bindings that belong to the global object environment. However, there is also an opportunity to cache the offset in the global declarative record. This change results in a 57% increase in speed for imaging-gaussian-blur.js in Kraken.
2023-07-12 04:06:59 +02:00
u32 m_next_global_variable_cache { 0 };
LibJS: Rename FunctionKind::{Regular => Normal} This is what CreateDynamicFunction calls it.
2022-01-15 00:30:02 +01:00
FunctionKind m_enclosing_function_kind { FunctionKind::Normal };
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
Vector<LabelableScope> m_continuable_scopes;
Vector<LabelableScope> m_breakable_scopes;
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
Vector<BlockBoundaryType> m_boundaries;
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
Vector<ScopedOperand> m_home_objects;
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
HashTable<u32> m_initialized_locals;
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
bool m_finished { false };
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
bool m_must_propagate_completion { true };
LibJS/Bytecode: Make Generator aware of the function it's compiling
2024-05-31 20:32:29 +02:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<ECMAScriptFunctionObject const> m_function;
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
Optional<IdentifierTableIndex> m_length_identifier;
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