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

120 lines
2.9 KiB
C++
Raw Normal View History

LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 13:19:50 +02:00
* Copyright (c) 2021, Andreas Kling <andreas@ladybird.org>
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
LibJS: 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/Bytecode/Executable.h>
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
#include <LibJS/Bytecode/Instruction.h>
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
#include <LibJS/Bytecode/Op.h>
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
namespace JS::Bytecode {
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
void Instruction::destroy(Instruction& instruction)
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: 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
#define __BYTECODE_OP(op) \
case Type::op: \
static_cast<Op::op&>(instruction).~op(); \
return;
switch (instruction.type()) {
ENUMERATE_BYTECODE_OPS(__BYTECODE_OP)
default:
VERIFY_NOT_REACHED();
}
#undef __BYTECODE_OP
}
LibJS/Bytecode: Flatten bytecode to a contiguous representation Instead of keeping bytecode as a set of disjoint basic blocks on the malloc heap, bytecode is now a contiguous sequence of bytes(!) The transformation happens at the end of Bytecode::Generator::generate() and the only really hairy part is rerouting jump labels. This required solving a few problems: - The interpreter execution loop had to change quite a bit, since we were storing BasicBlock pointers all over the place, and control transfer was done by redirecting the interpreter's current block. - Exception handlers & finalizers are now stored per-bytecode-range in a side table in Executable. - The interpreter now has a plain program counter instead of a stream iterator. This actually makes error stack generation a bit nicer since we just have to deal with a number instead of reaching into the iterator. This yields a 25% performance improvement on this microbenchmark: for (let i = 0; i < 1_000_000; ++i) { } But basically everything gets faster. :^)
2024-05-06 06:44:08 +02:00
void Instruction::visit_labels(Function<void(JS::Bytecode::Label&)> visitor)
{
#define __BYTECODE_OP(op) \
case Type::op: \
static_cast<Op::op&>(*this).visit_labels_impl(move(visitor)); \
return;
switch (type()) {
ENUMERATE_BYTECODE_OPS(__BYTECODE_OP)
default:
VERIFY_NOT_REACHED();
}
#undef __BYTECODE_OP
}
LibJS: Join locals, constants and registers into single vector Merging registers, constants and locals into single vector means: - Better data locality - No need to check type in Interpreter::get() and Interpreter::set() which are very hot functions Performance improvement is visible in almost all Octane and Kraken tests.
2024-05-12 18:49:03 +02:00
void Instruction::visit_operands(Function<void(JS::Bytecode::Operand&)> visitor)
{
#define __BYTECODE_OP(op) \
case Type::op: \
static_cast<Op::op&>(*this).visit_operands_impl(move(visitor)); \
return;
switch (type()) {
ENUMERATE_BYTECODE_OPS(__BYTECODE_OP)
default:
VERIFY_NOT_REACHED();
}
#undef __BYTECODE_OP
}
LibJS/Bytecode: Remove Instruction::m_length field Now that the interpreter is unrolled, we can advance the program counter manually based on the current instruction type. This makes most instructions a bit smaller. :^)
2024-05-06 11:09:09 +02:00
template<typename Op>
concept HasVariableLength = Op::IsVariableLength;
template<typename Op>
concept HasFixedLength = !Op::IsVariableLength;
template<HasVariableLength Op>
size_t get_length_impl(Op const& op)
{
return op.length_impl();
}
// Function template for types without a length_impl method
template<HasFixedLength Op>
size_t get_length_impl(Op const&)
{
return sizeof(Op);
}
size_t Instruction::length() const
{
#define __BYTECODE_OP(op) \
case Type::op: { \
auto& typed_op = static_cast<Op::op const&>(*this); \
return get_length_impl(typed_op); \
}
switch (type()) {
ENUMERATE_BYTECODE_OPS(__BYTECODE_OP)
default:
VERIFY_NOT_REACHED();
}
#undef __BYTECODE_OP
}
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
UnrealizedSourceRange InstructionStreamIterator::source_range() const
{
VERIFY(m_executable);
LibJS/Bytecode: Keep instruction source mappings in Executable Instead of storing source offsets with each instruction, we now keep them in a side table in Executable. This shrinks each instruction by 8 bytes, further improving locality.
2024-05-06 07:51:14 +02:00
auto record = m_executable->source_map.get(offset()).value();
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
return {
.source_code = m_executable->source_code,
.start_offset = record.source_start_offset,
.end_offset = record.source_end_offset,
};
}
RefPtr<SourceCode> InstructionStreamIterator::source_code() const
{
return m_executable ? m_executable->source_code.ptr() : nullptr;
}
LibJS/Bytecode: Add Bytecode::Operand An Operand is either a register, a local, or a constant (index into the executable's constant table)
2024-02-02 10:19:17 +01:00
Operand::Operand(Register reg)
: m_type(Type::Register)
, m_index(reg.index())
{
}
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
}
Reference in a new issue Copy permalink