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/Libraries/LibJS/Runtime/ExecutionContext.cpp

167 lines
6.9 KiB
C++
Raw Normal View History

LibJS: Move ExecutionContext function implementations out of line
2022-12-11 18:16:15 +00:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 13:19:50 +02:00
* Copyright (c) 2020-2024, Andreas Kling <andreas@ladybird.org>
LibJS: Move ExecutionContext function implementations out of line
2022-12-11 18:16:15 +00:00
* Copyright (c) 2020-2021, Linus Groh <linusg@serenityos.org>
* Copyright (c) 2022, Luke Wilde <lukew@serenityos.org>
LibJS: Put vector of regs+consts+locals+args in tail of ExecutionContext By doing that we avoid doing separate allocation for each such vector, which was really expensive on js heavy websites. For example this change helps to get EC allocation down from ~17% to ~2% on Google Maps. This comes at cost of adding extra complexity to custom execution context allocator, because EC no longer has fixed size and we need to maintain a list of buckets.
2025-04-23 19:44:54 +02:00
* Copyright (c) 2024-2025, Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
LibJS: Move ExecutionContext function implementations out of line
2022-12-11 18:16:15 +00:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
#include <LibGC/Heap.h>
LibJS: Make Bytecode::Executable GC-allocated This is a step towards making ExecutionContext easier to allocate.
2023-11-27 13:23:59 +01:00
#include <LibJS/Bytecode/Executable.h>
LibJS: Move ExecutionContext function implementations out of line
2022-12-11 18:16:15 +00:00
#include <LibJS/Runtime/ExecutionContext.h>
LibJS: Make it possible to visit the edges of an ExecutionContext
2022-12-11 18:24:33 +00:00
#include <LibJS/Runtime/FunctionObject.h>
LibJS: Move ExecutionContext function implementations out of line
2022-12-11 18:16:15 +00:00
namespace JS {
LibJS: Add fast ExecutionContext allocator ...that maintains a list of allocated execution contexts so malloc() does not have to be called every time we need to get a new one. 20% improvement in Octane/typescript.js 16% improvement in Kraken/imaging-darkroom.js
2024-05-23 11:10:23 +01:00
class ExecutionContextAllocator {
public:
LibJS: Put vector of regs+consts+locals+args in tail of ExecutionContext By doing that we avoid doing separate allocation for each such vector, which was really expensive on js heavy websites. For example this change helps to get EC allocation down from ~17% to ~2% on Google Maps. This comes at cost of adding extra complexity to custom execution context allocator, because EC no longer has fixed size and we need to maintain a list of buckets.
2025-04-23 19:44:54 +02:00
NonnullOwnPtr<ExecutionContext> allocate(u32 registers_and_constants_and_locals_count, u32 arguments_count)
LibJS: Add fast ExecutionContext allocator ...that maintains a list of allocated execution contexts so malloc() does not have to be called every time we need to get a new one. 20% improvement in Octane/typescript.js 16% improvement in Kraken/imaging-darkroom.js
2024-05-23 11:10:23 +01:00
{
LibJS: Put vector of regs+consts+locals+args in tail of ExecutionContext By doing that we avoid doing separate allocation for each such vector, which was really expensive on js heavy websites. For example this change helps to get EC allocation down from ~17% to ~2% on Google Maps. This comes at cost of adding extra complexity to custom execution context allocator, because EC no longer has fixed size and we need to maintain a list of buckets.
2025-04-23 19:44:54 +02:00
auto tail_size = registers_and_constants_and_locals_count + arguments_count;
void* slot = nullptr;
if (tail_size <= 4 && !m_execution_contexts_with_4_tail.is_empty()) {
slot = m_execution_contexts_with_4_tail.take_last();
} else if (tail_size <= 16 && !m_execution_contexts_with_16_tail.is_empty()) {
slot = m_execution_contexts_with_16_tail.take_last();
} else if (tail_size <= 64 && !m_execution_contexts_with_64_tail.is_empty()) {
slot = m_execution_contexts_with_64_tail.take_last();
} else if (tail_size <= 128 && !m_execution_contexts_with_128_tail.is_empty()) {
slot = m_execution_contexts_with_128_tail.take_last();
} else if (tail_size <= 256 && !m_execution_contexts_with_256_tail.is_empty()) {
slot = m_execution_contexts_with_256_tail.take_last();
} else if (tail_size <= 512 && !m_execution_contexts_with_512_tail.is_empty()) {
slot = m_execution_contexts_with_512_tail.take_last();
}
if (slot) {
return adopt_own(*new (slot) ExecutionContext(registers_and_constants_and_locals_count, arguments_count));
}
auto tail_allocation_size = [tail_size] -> u32 {
if (tail_size <= 4)
return 4;
if (tail_size <= 16)
return 16;
if (tail_size <= 64)
return 64;
if (tail_size <= 128)
return 128;
if (tail_size <= 256)
return 256;
if (tail_size <= 512)
return 512;
return tail_size;
};
auto* memory = ::operator new(sizeof(ExecutionContext) + tail_allocation_size() * sizeof(Value));
return adopt_own(*::new (memory) ExecutionContext(registers_and_constants_and_locals_count, arguments_count));
LibJS: Add fast ExecutionContext allocator ...that maintains a list of allocated execution contexts so malloc() does not have to be called every time we need to get a new one. 20% improvement in Octane/typescript.js 16% improvement in Kraken/imaging-darkroom.js
2024-05-23 11:10:23 +01:00
}
LibJS: Put vector of regs+consts+locals+args in tail of ExecutionContext By doing that we avoid doing separate allocation for each such vector, which was really expensive on js heavy websites. For example this change helps to get EC allocation down from ~17% to ~2% on Google Maps. This comes at cost of adding extra complexity to custom execution context allocator, because EC no longer has fixed size and we need to maintain a list of buckets.
2025-04-23 19:44:54 +02:00
void deallocate(void* ptr, u32 tail_size)
LibJS: Add fast ExecutionContext allocator ...that maintains a list of allocated execution contexts so malloc() does not have to be called every time we need to get a new one. 20% improvement in Octane/typescript.js 16% improvement in Kraken/imaging-darkroom.js
2024-05-23 11:10:23 +01:00
{
LibJS: Put vector of regs+consts+locals+args in tail of ExecutionContext By doing that we avoid doing separate allocation for each such vector, which was really expensive on js heavy websites. For example this change helps to get EC allocation down from ~17% to ~2% on Google Maps. This comes at cost of adding extra complexity to custom execution context allocator, because EC no longer has fixed size and we need to maintain a list of buckets.
2025-04-23 19:44:54 +02:00
if (tail_size <= 4) {
m_execution_contexts_with_4_tail.append(ptr);
} else if (tail_size <= 16) {
m_execution_contexts_with_16_tail.append(ptr);
} else if (tail_size <= 64) {
m_execution_contexts_with_64_tail.append(ptr);
} else if (tail_size <= 128) {
m_execution_contexts_with_128_tail.append(ptr);
} else if (tail_size <= 256) {
m_execution_contexts_with_256_tail.append(ptr);
} else if (tail_size <= 512) {
m_execution_contexts_with_512_tail.append(ptr);
} else {
::operator delete(ptr);
}
LibJS: Add fast ExecutionContext allocator ...that maintains a list of allocated execution contexts so malloc() does not have to be called every time we need to get a new one. 20% improvement in Octane/typescript.js 16% improvement in Kraken/imaging-darkroom.js
2024-05-23 11:10:23 +01:00
}
private:
LibJS: Put vector of regs+consts+locals+args in tail of ExecutionContext By doing that we avoid doing separate allocation for each such vector, which was really expensive on js heavy websites. For example this change helps to get EC allocation down from ~17% to ~2% on Google Maps. This comes at cost of adding extra complexity to custom execution context allocator, because EC no longer has fixed size and we need to maintain a list of buckets.
2025-04-23 19:44:54 +02:00
Vector<void*> m_execution_contexts_with_4_tail;
Vector<void*> m_execution_contexts_with_16_tail;
Vector<void*> m_execution_contexts_with_64_tail;
Vector<void*> m_execution_contexts_with_128_tail;
Vector<void*> m_execution_contexts_with_256_tail;
Vector<void*> m_execution_contexts_with_512_tail;
LibJS: Add fast ExecutionContext allocator ...that maintains a list of allocated execution contexts so malloc() does not have to be called every time we need to get a new one. 20% improvement in Octane/typescript.js 16% improvement in Kraken/imaging-darkroom.js
2024-05-23 11:10:23 +01:00
};
static NeverDestroyed<ExecutionContextAllocator> s_execution_context_allocator;
LibJS+LibWeb: Join arguments into vector of registers+constants+locals This is better because: - Better data locality - Allocate vector for registers+constants+locals+arguments in one go instead of allocating two vectors separately
2025-04-23 00:57:07 +02:00
NonnullOwnPtr<ExecutionContext> ExecutionContext::create(u32 registers_and_constants_and_locals_count, u32 arguments_count)
LibJS: Move ExecutionContext function implementations out of line
2022-12-11 18:16:15 +00:00
{
LibJS: Put vector of regs+consts+locals+args in tail of ExecutionContext By doing that we avoid doing separate allocation for each such vector, which was really expensive on js heavy websites. For example this change helps to get EC allocation down from ~17% to ~2% on Google Maps. This comes at cost of adding extra complexity to custom execution context allocator, because EC no longer has fixed size and we need to maintain a list of buckets.
2025-04-23 19:44:54 +02:00
return s_execution_context_allocator->allocate(registers_and_constants_and_locals_count, arguments_count);
LibJS: Add fast ExecutionContext allocator ...that maintains a list of allocated execution contexts so malloc() does not have to be called every time we need to get a new one. 20% improvement in Octane/typescript.js 16% improvement in Kraken/imaging-darkroom.js
2024-05-23 11:10:23 +01:00
}
void ExecutionContext::operator delete(void* ptr)
{
LibJS: Put vector of regs+consts+locals+args in tail of ExecutionContext By doing that we avoid doing separate allocation for each such vector, which was really expensive on js heavy websites. For example this change helps to get EC allocation down from ~17% to ~2% on Google Maps. This comes at cost of adding extra complexity to custom execution context allocator, because EC no longer has fixed size and we need to maintain a list of buckets.
2025-04-23 19:44:54 +02:00
auto const* execution_context = static_cast<ExecutionContext const*>(ptr);
s_execution_context_allocator->deallocate(ptr, execution_context->registers_and_constants_and_locals_and_arguments_count);
LibJS: Move ExecutionContext function implementations out of line
2022-12-11 18:16:15 +00:00
}
LibJS: Put vector of regs+consts+locals+args in tail of ExecutionContext By doing that we avoid doing separate allocation for each such vector, which was really expensive on js heavy websites. For example this change helps to get EC allocation down from ~17% to ~2% on Google Maps. This comes at cost of adding extra complexity to custom execution context allocator, because EC no longer has fixed size and we need to maintain a list of buckets.
2025-04-23 19:44:54 +02:00
ExecutionContext::ExecutionContext(u32 registers_and_constants_and_locals_count, u32 arguments_count)
LibJS: Move ExecutionContext function implementations out of line
2022-12-11 18:16:15 +00:00
{
LibJS: Put vector of regs+consts+locals+args in tail of ExecutionContext By doing that we avoid doing separate allocation for each such vector, which was really expensive on js heavy websites. For example this change helps to get EC allocation down from ~17% to ~2% on Google Maps. This comes at cost of adding extra complexity to custom execution context allocator, because EC no longer has fixed size and we need to maintain a list of buckets.
2025-04-23 19:44:54 +02:00
registers_and_constants_and_locals_and_arguments_count = registers_and_constants_and_locals_count + arguments_count;
arguments_offset = registers_and_constants_and_locals_count;
auto* registers_and_constants_and_locals_and_arguments = this->registers_and_constants_and_locals_and_arguments();
for (size_t i = 0; i < registers_and_constants_and_locals_count; ++i)
registers_and_constants_and_locals_and_arguments[i] = js_special_empty_value();
LibJS: Cache arguments span in ExecutionContext Allows us to avoid doing math in ExecutionContext::argument()
2025-04-24 01:37:30 +02:00
arguments = { registers_and_constants_and_locals_and_arguments + arguments_offset, registers_and_constants_and_locals_and_arguments_count - arguments_offset };
LibJS: Move ExecutionContext function implementations out of line
2022-12-11 18:16:15 +00:00
}
LibJS: Always allocate ExecutionContext objects on the malloc heap Instead of allocating these in a mixture of ways, we now always put them on the malloc heap, and keep an intrusive linked list of them that we can iterate for GC marking purposes.
2023-11-27 16:45:45 +01:00
ExecutionContext::~ExecutionContext()
LibJS: Move ExecutionContext function implementations out of line
2022-12-11 18:16:15 +00:00
{
LibJS: Always allocate ExecutionContext objects on the malloc heap Instead of allocating these in a mixture of ways, we now always put them on the malloc heap, and keep an intrusive linked list of them that we can iterate for GC marking purposes.
2023-11-27 16:45:45 +01:00
}
LibJS: Move ExecutionContext function implementations out of line
2022-12-11 18:16:15 +00:00
LibJS: Always allocate ExecutionContext objects on the malloc heap Instead of allocating these in a mixture of ways, we now always put them on the malloc heap, and keep an intrusive linked list of them that we can iterate for GC marking purposes.
2023-11-27 16:45:45 +01:00
NonnullOwnPtr<ExecutionContext> ExecutionContext::copy() const
{
LibJS: Cache arguments span in ExecutionContext Allows us to avoid doing math in ExecutionContext::argument()
2025-04-24 01:37:30 +02:00
auto copy = create(registers_and_constants_and_locals_and_arguments_count, arguments.size());
LibJS: Always allocate ExecutionContext objects on the malloc heap Instead of allocating these in a mixture of ways, we now always put them on the malloc heap, and keep an intrusive linked list of them that we can iterate for GC marking purposes.
2023-11-27 16:45:45 +01:00
copy->function = function;
copy->realm = realm;
copy->script_or_module = script_or_module;
copy->lexical_environment = lexical_environment;
copy->variable_environment = variable_environment;
copy->private_environment = private_environment;
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
copy->program_counter = program_counter;
LibJS: Always allocate ExecutionContext objects on the malloc heap Instead of allocating these in a mixture of ways, we now always put them on the malloc heap, and keep an intrusive linked list of them that we can iterate for GC marking purposes.
2023-11-27 16:45:45 +01:00
copy->function_name = function_name;
copy->this_value = this_value;
copy->is_strict_mode = is_strict_mode;
copy->executable = executable;
LibJS+LibWeb: Join arguments into vector of registers+constants+locals This is better because: - Better data locality - Allocate vector for registers+constants+locals+arguments in one go instead of allocating two vectors separately
2025-04-23 00:57:07 +02:00
copy->arguments_offset = arguments_offset;
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
copy->passed_argument_count = passed_argument_count;
LibJS: Merge CallFrame into ExecutionContext Before this change both ExecutionContext and CallFrame were created before executing function/module/script with a couple exceptions: - executable created for default function argument evaluation has to run in function's execution context. - `execute_ast_node()` where executable compiled for ASTNode has to be executed in running execution context. This change moves all members previously owned by CallFrame into ExecutionContext, and makes two exceptions where an executable that does not have a corresponding execution context saves and restores registers before running. Now, all execution state lives in a single entity, which makes it a bit easier to reason about and opens opportunities for optimizations, such as moving registers and local variables into a single array.
2024-05-01 19:33:49 +02:00
copy->unwind_contexts = unwind_contexts;
copy->saved_lexical_environments = saved_lexical_environments;
copy->previously_scheduled_jumps = previously_scheduled_jumps;
LibJS: Put vector of regs+consts+locals+args in tail of ExecutionContext By doing that we avoid doing separate allocation for each such vector, which was really expensive on js heavy websites. For example this change helps to get EC allocation down from ~17% to ~2% on Google Maps. This comes at cost of adding extra complexity to custom execution context allocator, because EC no longer has fixed size and we need to maintain a list of buckets.
2025-04-23 19:44:54 +02:00
copy->registers_and_constants_and_locals_and_arguments_count = registers_and_constants_and_locals_and_arguments_count;
for (size_t i = 0; i < registers_and_constants_and_locals_and_arguments_count; ++i)
copy->registers_and_constants_and_locals_and_arguments()[i] = registers_and_constants_and_locals_and_arguments()[i];
LibJS: Cache arguments span in ExecutionContext Allows us to avoid doing math in ExecutionContext::argument()
2025-04-24 01:37:30 +02:00
copy->arguments = { copy->registers_and_constants_and_locals_and_arguments() + copy->arguments_offset, arguments.size() };
LibJS: Move ExecutionContext function implementations out of line
2022-12-11 18:16:15 +00:00
return copy;
}
LibJS: Make it possible to visit the edges of an ExecutionContext
2022-12-11 18:24:33 +00:00
void ExecutionContext::visit_edges(Cell::Visitor& visitor)
{
visitor.visit(function);
visitor.visit(realm);
visitor.visit(variable_environment);
visitor.visit(lexical_environment);
visitor.visit(private_environment);
visitor.visit(context_owner);
LibJS: Make Value() default-construct the undefined value The special empty value (that we use for array holes, Optional<Value> when empty and a few other other placeholder/sentinel tasks) still exists, but you now create one via JS::js_special_empty_value() and check for it with Value::is_special_empty_value(). The main idea here is to make it very unlikely to accidentally create an unexpected special empty value.
2025-04-04 23:16:34 +02:00
if (this_value.has_value())
visitor.visit(*this_value);
LibJS: Always allocate ExecutionContext objects on the malloc heap Instead of allocating these in a mixture of ways, we now always put them on the malloc heap, and keep an intrusive linked list of them that we can iterate for GC marking purposes.
2023-11-27 16:45:45 +01:00
visitor.visit(executable);
LibJS: Make ExecutionContext::function_name a GCPtr<PrimitiveString> This required setting things up so that all function objects can plop a PrimitiveString there instead of an AK string. This is a step towards making ExecutionContext easier to allocate.
2023-11-27 13:38:19 +01:00
visitor.visit(function_name);
LibJS: Put vector of regs+consts+locals+args in tail of ExecutionContext By doing that we avoid doing separate allocation for each such vector, which was really expensive on js heavy websites. For example this change helps to get EC allocation down from ~17% to ~2% on Google Maps. This comes at cost of adding extra complexity to custom execution context allocator, because EC no longer has fixed size and we need to maintain a list of buckets.
2025-04-23 19:44:54 +02:00
visitor.visit(registers_and_constants_and_locals_and_arguments_span());
LibJS: Merge CallFrame into ExecutionContext Before this change both ExecutionContext and CallFrame were created before executing function/module/script with a couple exceptions: - executable created for default function argument evaluation has to run in function's execution context. - `execute_ast_node()` where executable compiled for ASTNode has to be executed in running execution context. This change moves all members previously owned by CallFrame into ExecutionContext, and makes two exceptions where an executable that does not have a corresponding execution context saves and restores registers before running. Now, all execution state lives in a single entity, which makes it a bit easier to reason about and opens opportunities for optimizations, such as moving registers and local variables into a single array.
2024-05-01 19:33:49 +02:00
for (auto& context : unwind_contexts) {
visitor.visit(context.lexical_environment);
}
visitor.visit(saved_lexical_environments);
LibJS: Make it possible to visit the edges of an ExecutionContext
2022-12-11 18:24:33 +00:00
script_or_module.visit(
[](Empty) {},
[&](auto& script_or_module) {
visitor.visit(script_or_module);
});
}
LibJS: Move ExecutionContext function implementations out of line
2022-12-11 18:16:15 +00:00
}
Reference in a new issue Copy permalink