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

310 lines
11 KiB
C
Raw Normal View History

LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
/*
LibJS/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
* Copyright (c) 2021-2024, Andreas Kling <kling@serenityos.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/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
static CodeGenerationErrorOr<NonnullGCPtr<Executable>> generate(VM&, ASTNode const&, ReadonlySpan<FunctionParameter> parameters, FunctionKind = FunctionKind::Normal);
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
Register allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
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: 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();
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)
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
m_current_basic_block->terminate({});
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
auto* op = static_cast<OpType*>(slot);
op->set_source_record({ 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
}
template<typename OpType, typename... Args>
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 emit_with_extra_operand_slots(size_t extra_operand_slots, 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: 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
size_t size_to_allocate = round_up_to_power_of_two(sizeof(OpType) + extra_operand_slots * sizeof(Operand), 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: 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)
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
m_current_basic_block->terminate({});
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
auto* op = static_cast<OpType*>(slot);
op->set_source_record({ 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: 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 {
Optional<Operand> base {}; // [[Base]]
Optional<Operand> referenced_name {}; // [[ReferencedName]] as an operand
Optional<IdentifierTableIndex> referenced_identifier {}; // [[ReferencedName]] as an identifier
Optional<IdentifierTableIndex> referenced_private_identifier {}; // [[ReferencedName]] as a private identifier
Optional<Operand> this_value {}; // [[ThisValue]]
Optional<Operand> 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: 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_load_from_reference(JS::ASTNode const&, Optional<Operand> preferred_dst = {});
CodeGenerationErrorOr<void> emit_store_to_reference(JS::ASTNode const&, Operand value);
CodeGenerationErrorOr<void> emit_store_to_reference(ReferenceOperands const&, Operand value);
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
CodeGenerationErrorOr<Optional<Operand>> 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: 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 emit_set_variable(JS::Identifier const& identifier, Operand value, Bytecode::Op::SetVariable::InitializationMode initialization_mode = Bytecode::Op::SetVariable::InitializationMode::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: 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 push_home_object(Operand);
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: 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 emit_new_function(Operand 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: 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<Optional<Operand>> emit_named_evaluation_if_anonymous_function(Expression const&, Optional<IdentifierTableIndex> lhs_name, Optional<Operand> 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
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
void begin_continuable_scope(Label continue_target, Vector<DeprecatedFlyString> 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();
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
void begin_breakable_scope(Label breakable_target, Vector<DeprecatedFlyString> 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())
LibJS: Migrate DeprecatedString to String This changes BasicBlock's constructor and create().
2023-10-26 23:57:51 -04:00
name = MUST(String::number(m_next_block++));
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
auto block = BasicBlock::create(name);
if (auto const* context = m_current_unwind_context) {
if (context->handler().has_value())
block->set_handler(context->handler().value().block());
if (m_current_unwind_context->finalizer().has_value())
block->set_finalizer(context->finalizer().value().block());
}
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
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
StringTableIndex intern_string(ByteString 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));
}
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
IdentifierTableIndex intern_identifier(DeprecatedFlyString 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/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: 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 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/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: 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: 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();
void generate_break(DeprecatedFlyString const& break_label);
LibJS: Generate unwind chains for continue in Bytecode This works similar to `break` The `try-finally-continue` still do not pass with this, likely because of binding issues.
2022-11-25 16:35:39 +01:00
void generate_continue();
void generate_continue(DeprecatedFlyString 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: 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: 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 emit_get_by_id(Operand dst, Operand base, IdentifierTableIndex);
void emit_get_by_id_with_this(Operand dst, Operand base, IdentifierTableIndex, Operand 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: 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 emit_iterator_value(Operand dst, Operand result);
void emit_iterator_complete(Operand dst, Operand 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/Bytecode: Move environment coordinate caches to Executable Moving them out of the respective instructions allows the bytecode stream to be immutable.
2023-10-26 10:39:40 +02:00
[[nodiscard]] size_t next_environment_variable_cache() { return m_next_environment_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,
};
[[nodiscard]] Operand add_constant(Value value, DeduplicateConstant deduplicate_constant = DeduplicateConstant::Yes)
LibJS/Bytecode: Add constants table to Bytecode::Executable
2024-02-02 09:52:25 +01:00
{
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
if (deduplicate_constant == DeduplicateConstant::Yes) {
for (size_t i = 0; i < m_constants.size(); ++i) {
if (m_constants[i] == value)
return Operand(Operand::Type::Constant, i);
}
LibJS/Bytecode: Add constants table to Bytecode::Executable
2024-02-02 09:52:25 +01:00
}
m_constants.append(value);
return Operand(Operand::Type::Constant, m_constants.size() - 1);
}
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: 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: Deduplicate labelled continue & break bytecode generation Similar to the scoped continue and break, the only two differences between these functions is the scope that is scanned for a matching label, and the specific handling of a continue/break boundary.
2023-07-19 20:06:25 +12:00
void generate_labelled_jump(JumpType, DeprecatedFlyString 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
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
explicit Generator(VM&);
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: 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;
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
Vector<DeprecatedFlyString> 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;
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
MarkedVector<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: 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/Bytecode: Move environment coordinate caches to Executable Moving them out of the respective instructions allows the bytecode stream to be immutable.
2023-10-26 10:39:40 +02:00
u32 m_next_environment_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: 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
Vector<Operand> m_home_objects;
HashTable<u32> m_initialized_locals;
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