Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-04 07:10:57 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibJS/Bytecode/Interpreter.h

124 lines
4 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
/*
* Copyright (c) 2021, Andreas Kling <kling@serenityos.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
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: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
#include <LibJS/Bytecode/Register.h>
#include <LibJS/Forward.h>
#include <LibJS/Heap/Cell.h>
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
#include <LibJS/Heap/Handle.h>
LibJS/Bytecode: Simplify Bytecode::Interpreter lifetime model The JS::VM now owns the one Bytecode::Interpreter. We no longer have multiple bytecode interpreters, and there is no concept of a "current" bytecode interpreter. If you ask for VM::bytecode_interpreter_if_exists(), it will return null if we're not running the program in "bytecode enabled" mode. If you ask for VM::bytecode_interpreter(), it will return a bytecode interpreter in all modes. This is used for situations where even the AST interpreter switches to bytecode mode (generators, etc.)
2023-06-22 15:59:18 +02:00
#include <LibJS/Runtime/FunctionKind.h>
LibJS: Implement the NewClass opcode
2022-02-11 22:38:21 +03:30
#include <LibJS/Runtime/VM.h>
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
#include <LibJS/Runtime/Value.h>
namespace JS::Bytecode {
Ladybird+LibJS: Add CLI option to run browser with LibJS bytecode VM This required quite a bit of plumbing, but now you can run ladybird --use-bytecode
2023-06-17 13:16:35 +02:00
class InstructionStreamIterator;
class PassManager;
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
struct RegisterWindow {
MarkedVector<Value> registers;
LibJS+LibWeb: Wrap raw JS::Cell*/& fields in GCPtr/NonnullGCPtr
2023-02-26 16:09:02 -07:00
MarkedVector<GCPtr<Environment>> saved_lexical_environments;
MarkedVector<GCPtr<Environment>> saved_variable_environments;
LibJS/Bytecode: Store unwind contexts inside RegisterWindow Unwind contexts need to be preserved as we exit and re-enter a generator. For example, this would previously crash when returning from the try statement after yielding as we lost the unwind context when yielding, but still have a LeaveUnwindContext instruction from running `perform_needed_unwinds` when generating the return statement. ```js function* a() { try { return (yield 1); } catch {} } iter = a(); iter.next(); iter.next(); ```
2022-11-25 23:15:44 +00:00
Vector<UnwindInfo> unwind_contexts;
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: Compile ScriptFunctions into bytecode and run them that way :^) If there's a current Bytecode::Interpreter in action, ScriptFunction will now compile itself into bytecode and execute in that context. This patch also adds the Return bytecode instruction so that we can actually return values from called functions. :^) Return values are propagated from callee to caller via the caller's $0 register. Bytecode::Interpreter now keeps a stack of register "windows". These are not very efficient, but it should be pretty straightforward to convert them to e.g a sliding register window architecture later on. This is pretty dang cool! :^)
2021-06-05 15:53:36 +02:00
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
class Interpreter {
public:
Ladybird+LibJS: Add CLI option to run browser with LibJS bytecode VM This required quite a bit of plumbing, but now you can run ladybird --use-bytecode
2023-06-17 13:16:35 +02:00
[[nodiscard]] static bool enabled();
static void set_enabled(bool);
test262-runner+js: Respect the bytecode optimizations enabled flag
2023-06-26 19:50:33 +02:00
static void set_optimizations_enabled(bool);
Ladybird+LibJS: Add CLI option to run browser with LibJS bytecode VM This required quite a bit of plumbing, but now you can run ladybird --use-bytecode
2023-06-17 13:16:35 +02:00
LibJS/Bytecode: Simplify Bytecode::Interpreter lifetime model The JS::VM now owns the one Bytecode::Interpreter. We no longer have multiple bytecode interpreters, and there is no concept of a "current" bytecode interpreter. If you ask for VM::bytecode_interpreter_if_exists(), it will return null if we're not running the program in "bytecode enabled" mode. If you ask for VM::bytecode_interpreter(), it will return a bytecode interpreter in all modes. This is used for situations where even the AST interpreter switches to bytecode mode (generators, etc.)
2023-06-22 15:59:18 +02:00
explicit Interpreter(VM&);
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
~Interpreter();
LibJS/Bytecode: Simplify Bytecode::Interpreter lifetime model The JS::VM now owns the one Bytecode::Interpreter. We no longer have multiple bytecode interpreters, and there is no concept of a "current" bytecode interpreter. If you ask for VM::bytecode_interpreter_if_exists(), it will return null if we're not running the program in "bytecode enabled" mode. If you ask for VM::bytecode_interpreter(), it will return a bytecode interpreter in all modes. This is used for situations where even the AST interpreter switches to bytecode mode (generators, etc.)
2023-06-22 15:59:18 +02:00
Realm& realm();
LibJS: Add a VM accessor to Bytecode::Interpreter :^)
2021-06-03 18:26:13 +02:00
VM& vm() { return m_vm; }
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: Leave GlobalDeclarationInstantiation in C++ Don't try to implement this AO in bytecode. Instead, the bytecode Interpreter class now has a run() API with the same inputs as the AST interpreter. It sets up the necessary environments etc, including invoking the GlobalDeclarationInstantiation AO.
2023-06-15 12:36:57 +02:00
ThrowCompletionOr<Value> run(Script&, JS::GCPtr<Environment> lexical_environment_override = nullptr);
ThrowCompletionOr<Value> run(SourceTextModule&);
LibJS/Bytecode: Simplify Bytecode::Interpreter lifetime model The JS::VM now owns the one Bytecode::Interpreter. We no longer have multiple bytecode interpreters, and there is no concept of a "current" bytecode interpreter. If you ask for VM::bytecode_interpreter_if_exists(), it will return null if we're not running the program in "bytecode enabled" mode. If you ask for VM::bytecode_interpreter(), it will return a bytecode interpreter in all modes. This is used for situations where even the AST interpreter switches to bytecode mode (generators, etc.)
2023-06-22 15:59:18 +02:00
ThrowCompletionOr<Value> run(Realm& realm, Bytecode::Executable const& executable, Bytecode::BasicBlock const* entry_point = nullptr)
LibJS: Make Bytecode::Interpreter return the popped frame And use it to _correctly_ implement state saving for generators. Prior to this, we were capturing the caller frame, which is completely irrelevant to the generator frame.
2021-11-11 00:34:44 +03:30
{
LibJS/Bytecode: Simplify Bytecode::Interpreter lifetime model The JS::VM now owns the one Bytecode::Interpreter. We no longer have multiple bytecode interpreters, and there is no concept of a "current" bytecode interpreter. If you ask for VM::bytecode_interpreter_if_exists(), it will return null if we're not running the program in "bytecode enabled" mode. If you ask for VM::bytecode_interpreter(), it will return a bytecode interpreter in all modes. This is used for situations where even the AST interpreter switches to bytecode mode (generators, etc.)
2023-06-22 15:59:18 +02:00
auto value_and_frame = run_and_return_frame(realm, executable, entry_point);
LibJS: Implement the NewClass opcode
2022-02-11 22:38:21 +03:30
return move(value_and_frame.value);
LibJS: Make Bytecode::Interpreter return the popped frame And use it to _correctly_ implement state saving for generators. Prior to this, we were capturing the caller frame, which is completely irrelevant to the generator frame.
2021-11-11 00:34:44 +03:30
}
struct ValueAndFrame {
LibJS+LibTest+js: Convert BC::Interpreter::run to ThrowCompletionOr<> Note that this is just a shallow API change.
2021-11-11 04:11:56 +03:30
ThrowCompletionOr<Value> value;
LibJS: Make Bytecode::Interpreter return the popped frame And use it to _correctly_ implement state saving for generators. Prior to this, we were capturing the caller frame, which is completely irrelevant to the generator frame.
2021-11-11 00:34:44 +03:30
OwnPtr<RegisterWindow> frame;
};
LibJS/Bytecode: Simplify Bytecode::Interpreter lifetime model The JS::VM now owns the one Bytecode::Interpreter. We no longer have multiple bytecode interpreters, and there is no concept of a "current" bytecode interpreter. If you ask for VM::bytecode_interpreter_if_exists(), it will return null if we're not running the program in "bytecode enabled" mode. If you ask for VM::bytecode_interpreter(), it will return a bytecode interpreter in all modes. This is used for situations where even the AST interpreter switches to bytecode mode (generators, etc.)
2023-06-22 15:59:18 +02:00
ValueAndFrame run_and_return_frame(Realm&, Bytecode::Executable const&, Bytecode::BasicBlock const* entry_point, RegisterWindow* = 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
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
ALWAYS_INLINE Value& accumulator() { return reg(Register::accumulator()); }
LibJS: Compile ScriptFunctions into bytecode and run them that way :^) If there's a current Bytecode::Interpreter in action, ScriptFunction will now compile itself into bytecode and execute in that context. This patch also adds the Return bytecode instruction so that we can actually return values from called functions. :^) Return values are propagated from callee to caller via the caller's $0 register. Bytecode::Interpreter now keeps a stack of register "windows". These are not very efficient, but it should be pretty straightforward to convert them to e.g a sliding register window architecture later on. This is pretty dang cool! :^)
2021-06-05 15:53:36 +02:00
Value& reg(Register const& r) { return registers()[r.index()]; }
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
LibJS: Avoid copying the frame into the interpreter in BC generators
2022-04-15 20:20:51 +04:30
auto& saved_lexical_environment_stack() { return window().saved_lexical_environments; }
auto& saved_variable_environment_stack() { return window().saved_variable_environments; }
LibJS/Bytecode: Store unwind contexts inside RegisterWindow Unwind contexts need to be preserved as we exit and re-enter a generator. For example, this would previously crash when returning from the try statement after yielding as we lost the unwind context when yielding, but still have a LeaveUnwindContext instruction from running `perform_needed_unwinds` when generating the return statement. ```js function* a() { try { return (yield 1); } catch {} } iter = a(); iter.next(); iter.next(); ```
2022-11-25 23:15:44 +00:00
auto& unwind_contexts() { return window().unwind_contexts; }
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
void jump(Label const& label)
{
m_pending_jump = &label.block();
}
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 schedule_jump(Label const& label)
{
m_scheduled_jump = &label.block();
VERIFY(unwind_contexts().last().finalizer);
jump(Label { *unwind_contexts().last().finalizer });
}
LibJS: Align codegen AwaitExpressions to YieldExpressions We use generators in bytecode to approximate async functions, but the code generated by AwaitExpressions did not have the value processing paths that Yield requires, eg the `generator.throw()` path, which is used by AsyncFunctionDriverWrapper to signal Promise rejections.
2022-12-25 17:15:29 +01:00
void do_return(Value return_value)
{
m_return_value = return_value;
m_saved_exception = {};
}
LibJS: Add basic support for while loops in the bytecode engine This introduces two new instructions: Jump and JumpIfFalse. Jumps are made to a Bytecode::Label, which is a simple object that represents a location in the bytecode stream. Note that you may not always know the target of a jump when adding the jump instruction itself, but we can just update the instruction later on during codegen once we know where the jump target is. The Bytecode::Interpreter now implements jumping via a jump slot that gets checked after each instruction to see if a jump is pending. If not, we just increment the PC as usual.
2021-06-04 12:07:38 +02:00
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
void enter_unwind_context(Optional<Label> handler_target, Optional<Label> finalizer_target);
void leave_unwind_context();
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> continue_pending_unwind(Label const& resume_label);
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
LibJS: 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
Executable const& current_executable() { return *m_current_executable; }
LibJS: Expose some information about the bytecode interpreters state This is quite helpful, when reporting internal errors.
2022-10-30 11:58:46 +01:00
BasicBlock const& current_block() const { return *m_current_block; }
Ladybird+LibJS: Add CLI option to run browser with LibJS bytecode VM This required quite a bit of plumbing, but now you can run ladybird --use-bytecode
2023-06-17 13:16:35 +02:00
size_t pc() const;
DeprecatedString debug_position() const;
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: Remove the concept of bytecode optimization levels While this would be useful in the future for implementing a multi-tiered optimization strategy, currently a binary on/off is enough for us. This removes the confusingly on-by-default `OptimizationLevel::None` option which made the optimization pipeline a no-op even if `Bytecode::Interpreter::set_optimizations_enabled` had been called. Fixes #15982
2023-06-26 20:10:11 +02:00
static Bytecode::PassManager& optimization_pipeline();
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 20:40:20 +04:30
LibJS/Bytecode: Simplify Bytecode::Interpreter lifetime model The JS::VM now owns the one Bytecode::Interpreter. We no longer have multiple bytecode interpreters, and there is no concept of a "current" bytecode interpreter. If you ask for VM::bytecode_interpreter_if_exists(), it will return null if we're not running the program in "bytecode enabled" mode. If you ask for VM::bytecode_interpreter(), it will return a bytecode interpreter in all modes. This is used for situations where even the AST interpreter switches to bytecode mode (generators, etc.)
2023-06-22 15:59:18 +02:00
VM::InterpreterExecutionScope ast_interpreter_scope(Realm&);
LibJS: Implement the NewClass opcode
2022-02-11 22:38:21 +03:30
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: Avoid copying the frame into the interpreter in BC generators
2022-04-15 20:20:51 +04:30
RegisterWindow& window()
{
return m_register_windows.last().visit([](auto& x) -> RegisterWindow& { return *x; });
}
RegisterWindow const& window() const
{
return const_cast<Interpreter*>(this)->window();
}
MarkedVector<Value>& registers() { return window().registers; }
LibJS: Compile ScriptFunctions into bytecode and run them that way :^) If there's a current Bytecode::Interpreter in action, ScriptFunction will now compile itself into bytecode and execute in that context. This patch also adds the Return bytecode instruction so that we can actually return values from called functions. :^) Return values are propagated from callee to caller via the caller's $0 register. Bytecode::Interpreter now keeps a stack of register "windows". These are not very efficient, but it should be pretty straightforward to convert them to e.g a sliding register window architecture later on. This is pretty dang cool! :^)
2021-06-05 15:53:36 +02:00
LibJS: Add a VM accessor to Bytecode::Interpreter :^)
2021-06-03 18:26:13 +02:00
VM& m_vm;
LibJS: Avoid copying the frame into the interpreter in BC generators
2022-04-15 20:20:51 +04:30
Vector<Variant<NonnullOwnPtr<RegisterWindow>, RegisterWindow*>> m_register_windows;
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
Optional<BasicBlock const*> m_pending_jump;
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
BasicBlock const* m_scheduled_jump { nullptr };
LibJS: Compile ScriptFunctions into bytecode and run them that way :^) If there's a current Bytecode::Interpreter in action, ScriptFunction will now compile itself into bytecode and execute in that context. This patch also adds the Return bytecode instruction so that we can actually return values from called functions. :^) Return values are propagated from callee to caller via the caller's $0 register. Bytecode::Interpreter now keeps a stack of register "windows". These are not very efficient, but it should be pretty straightforward to convert them to e.g a sliding register window architecture later on. This is pretty dang cool! :^)
2021-06-05 15:53:36 +02:00
Value m_return_value;
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
Handle<Value> m_saved_return_value;
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
Executable const* m_current_executable { nullptr };
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
Handle<Value> m_saved_exception;
LibJS: Implement the NewClass opcode
2022-02-11 22:38:21 +03:30
OwnPtr<JS::Interpreter> m_ast_interpreter;
LibJS: Expose some information about the bytecode interpreters state This is quite helpful, when reporting internal errors.
2022-10-30 11:58:46 +01:00
BasicBlock const* m_current_block { nullptr };
InstructionStreamIterator* m_pc { 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
};
LibJS: Move global "should dump bytecode" flag into LibJS This will allow us to trigger bytecode executable dumps when generating bytecode inside LibJS as well, not just in clients like js and test-js.
2021-10-24 13:34:46 +02:00
extern bool g_dump_bytecode;
LibJS/Bytecode: Simplify Bytecode::Interpreter lifetime model The JS::VM now owns the one Bytecode::Interpreter. We no longer have multiple bytecode interpreters, and there is no concept of a "current" bytecode interpreter. If you ask for VM::bytecode_interpreter_if_exists(), it will return null if we're not running the program in "bytecode enabled" mode. If you ask for VM::bytecode_interpreter(), it will return a bytecode interpreter in all modes. This is used for situations where even the AST interpreter switches to bytecode mode (generators, etc.)
2023-06-22 15:59:18 +02:00
ThrowCompletionOr<NonnullOwnPtr<Bytecode::Executable>> compile(VM&, ASTNode const& no, JS::FunctionKind kind, DeprecatedFlyString const& name);
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