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

363 lines
14 KiB
C
Raw Normal View History

LibJS+Clients: Add JS::VM object, separate Heap from Interpreter Taking a big step towards a world of multiple global object, this patch adds a new JS::VM object that houses the JS::Heap. This means that the Heap moves out of Interpreter, and the same Heap can now be used by multiple Interpreters, and can also outlive them. The VM keeps a stack of Interpreter pointers. We push/pop on this stack when entering/exiting execution with a given Interpreter. This allows us to make this change without disturbing too much of the existing code. There is still a 1-to-1 relationship between Interpreter and the global object. This will change in the future. Ultimately, the goal here is to make Interpreter a transient object that only needs to exist while you execute some code. Getting there will take a lot more work though. :^) Note that in LibWeb, the global JS::VM is called main_thread_vm(), to distinguish it from future worker VM's.
2020-09-20 19:24:44 +02:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 13:19:50 +02:00
* Copyright (c) 2020-2023, Andreas Kling <andreas@ladybird.org>
LibJS: Port Symbol to String This includes the VM's global_symbol_registry HashMap, which can now store String keys.
2023-02-11 16:14:41 +00:00
* Copyright (c) 2020-2023, Linus Groh <linusg@serenityos.org>
LibJS: Implement HostResolveImportedModule for LibJS This loads modules with relative paths from the referencing module. In this commit the only way to run a module is via the interpreter which can link and evaluate a module (and all its dependencies).
2022-01-19 01:22:58 +01:00
* Copyright (c) 2021-2022, David Tuin <davidot@serenityos.org>
LibJS+LibWeb: Bring script fetching closer to the spec This patch updates various parts of the script fetching implementation to match the current specification. Notably, the implementation of changes to the import assertions / attributes proposal are not part of this patch(series).
2023-10-29 02:53:53 +01:00
* Copyright (c) 2023, networkException <networkexception@serenityos.org>
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter Taking a big step towards a world of multiple global object, this patch adds a new JS::VM object that houses the JS::Heap. This means that the Heap moves out of Interpreter, and the same Heap can now be used by multiple Interpreters, and can also outlive them. The VM keeps a stack of Interpreter pointers. We push/pop on this stack when entering/exiting execution with a given Interpreter. This allows us to make this change without disturbing too much of the existing code. There is still a 1-to-1 relationship between Interpreter and the global object. This will change in the future. Ultimately, the goal here is to make Interpreter a transient object that only needs to exist while you execute some code. Getting there will take a lot more work though. :^) Note that in LibWeb, the global JS::VM is called main_thread_vm(), to distinguish it from future worker VM's.
2020-09-20 19:24:44 +02:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 01:24:48 -07:00
* SPDX-License-Identifier: BSD-2-Clause
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter Taking a big step towards a world of multiple global object, this patch adds a new JS::VM object that houses the JS::Heap. This means that the Heap moves out of Interpreter, and the same Heap can now be used by multiple Interpreters, and can also outlive them. The VM keeps a stack of Interpreter pointers. We push/pop on this stack when entering/exiting execution with a given Interpreter. This allows us to make this change without disturbing too much of the existing code. There is still a 1-to-1 relationship between Interpreter and the global object. This will change in the future. Ultimately, the goal here is to make Interpreter a transient object that only needs to exist while you execute some code. Getting there will take a lot more work though. :^) Note that in LibWeb, the global JS::VM is called main_thread_vm(), to distinguish it from future worker VM's.
2020-09-20 19:24:44 +02:00
*/
#pragma once
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
#include <AK/DeprecatedFlyString.h>
LibJS: Add initial support for Promises Almost a year after first working on this, it's finally done: an implementation of Promises for LibJS! :^) The core functionality is working and closely following the spec [1]. I mostly took the pseudo code and transformed it into C++ - if you read and understand it, you will know how the spec implements Promises; and if you read the spec first, the code will look very familiar. Implemented functions are: - Promise() constructor - Promise.prototype.then() - Promise.prototype.catch() - Promise.prototype.finally() - Promise.resolve() - Promise.reject() For the tests I added a new function to test-js's global object, runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs(). By design, queued jobs normally only run after the script was fully executed, making it improssible to test handlers in individual test() calls by default [2]. Subsequent commits include integrations into LibWeb and js(1) - pretty-printing, running queued promise jobs when necessary. This has an unusual amount of dbgln() statements, all hidden behind the PROMISE_DEBUG flag - I'm leaving them in for now as they've been very useful while debugging this, things can get quite complex with so many asynchronously executed functions. I've not extensively explored use of these APIs for promise-based functionality in LibWeb (fetch(), Notification.requestPermission() etc.), but we'll get there in due time. [1]: https://tc39.es/ecma262/#sec-promise-objects [2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues
2021-04-01 22:13:29 +02:00
#include <AK/Function.h>
LibJS: Move well-known symbols to the VM No need to instantiate unique symbols for each Interpreter; they can be VM-global. This reduces the memory cost and startup time anyway.
2020-09-22 16:18:51 +02:00
#include <AK/HashMap.h>
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter Taking a big step towards a world of multiple global object, this patch adds a new JS::VM object that houses the JS::Heap. This means that the Heap moves out of Interpreter, and the same Heap can now be used by multiple Interpreters, and can also outlive them. The VM keeps a stack of Interpreter pointers. We push/pop on this stack when entering/exiting execution with a given Interpreter. This allows us to make this change without disturbing too much of the existing code. There is still a 1-to-1 relationship between Interpreter and the global object. This will change in the future. Ultimately, the goal here is to make Interpreter a transient object that only needs to exist while you execute some code. Getting there will take a lot more work though. :^) Note that in LibWeb, the global JS::VM is called main_thread_vm(), to distinguish it from future worker VM's.
2020-09-20 19:24:44 +02:00
#include <AK/RefCounted.h>
LibJS+AK: Move cross-platform stack bounds code from JS::Heap to AK::StackInfo This will be useful for other things than the Heap, maybe even outside of LibJS.
2020-11-08 12:48:16 +00:00
#include <AK/StackInfo.h>
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
#include <AK/Variant.h>
LibJS+LibWeb: Bring script fetching closer to the spec This patch updates various parts of the script fetching implementation to match the current specification. Notably, the implementation of changes to the import assertions / attributes proposal are not part of this patch(series).
2023-10-29 02:53:53 +01:00
#include <LibJS/CyclicModule.h>
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter Taking a big step towards a world of multiple global object, this patch adds a new JS::VM object that houses the JS::Heap. This means that the Heap moves out of Interpreter, and the same Heap can now be used by multiple Interpreters, and can also outlive them. The VM keeps a stack of Interpreter pointers. We push/pop on this stack when entering/exiting execution with a given Interpreter. This allows us to make this change without disturbing too much of the existing code. There is still a 1-to-1 relationship between Interpreter and the global object. This will change in the future. Ultimately, the goal here is to make Interpreter a transient object that only needs to exist while you execute some code. Getting there will take a lot more work though. :^) Note that in LibWeb, the global JS::VM is called main_thread_vm(), to distinguish it from future worker VM's.
2020-09-20 19:24:44 +02:00
#include <LibJS/Heap/Heap.h>
LibJS: Replace uses of MarkedValueList with MarkedVector<Value> This is effectively a drop-in replacement.
2022-02-09 10:06:40 +00:00
#include <LibJS/Heap/MarkedVector.h>
LibJS+LibWeb: Another round of bringing module loading closer to spec In particular, this patch focuses on: - Updating the old "import assertions" to the new "import attributes" - Allowing realms as module import referrer
2023-12-02 16:20:01 +01:00
#include <LibJS/ModuleLoading.h>
LibJS: Cache commonly used FlyStrings in the VM Roughly 7% of test-js runtime was spent creating FlyStrings from string literals. This patch frontloads that work and caches all the commonly used names in LibJS on a CommonPropertyNames struct that hangs off VM.
2020-10-13 23:49:19 +02:00
#include <LibJS/Runtime/CommonPropertyNames.h>
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
#include <LibJS/Runtime/Completion.h>
LibJS: Throw RuntimeError when reaching the end of the stack This prevents stack overflows when calling infinite/deep recursive functions, e.g.: const f = () => f(); f(); JSON.stringify({}, () => ({ foo: "bar" })); new Proxy({}, { get: (_, __, p) => p.foo }).foo; The VM caches a StackInfo object to not slow down function calls considerably. VM::push_call_frame() will throw an exception if necessary (plain Error with "RuntimeError" as its .name).
2020-11-08 12:54:52 +00:00
#include <LibJS/Runtime/Error.h>
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
#include <LibJS/Runtime/ErrorTypes.h>
LibJS: Reorganize ExecutionContext a little bit - Move it to a separate header file - Annotate the members that represent spec slots - Reorganize the members (by spec vs non-spec)
2021-09-14 18:21:07 +02:00
#include <LibJS/Runtime/ExecutionContext.h>
LibJS: Add initial support for Promises Almost a year after first working on this, it's finally done: an implementation of Promises for LibJS! :^) The core functionality is working and closely following the spec [1]. I mostly took the pseudo code and transformed it into C++ - if you read and understand it, you will know how the spec implements Promises; and if you read the spec first, the code will look very familiar. Implemented functions are: - Promise() constructor - Promise.prototype.then() - Promise.prototype.catch() - Promise.prototype.finally() - Promise.resolve() - Promise.reject() For the tests I added a new function to test-js's global object, runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs(). By design, queued jobs normally only run after the script was fully executed, making it improssible to test handlers in individual test() calls by default [2]. Subsequent commits include integrations into LibWeb and js(1) - pretty-printing, running queued promise jobs when necessary. This has an unusual amount of dbgln() statements, all hidden behind the PROMISE_DEBUG flag - I'm leaving them in for now as they've been very useful while debugging this, things can get quite complex with so many asynchronously executed functions. I've not extensively explored use of these APIs for promise-based functionality in LibWeb (fetch(), Notification.requestPermission() etc.), but we'll get there in due time. [1]: https://tc39.es/ecma262/#sec-promise-objects [2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues
2021-04-01 22:13:29 +02:00
#include <LibJS/Runtime/Promise.h>
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
#include <LibJS/Runtime/Value.h>
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter Taking a big step towards a world of multiple global object, this patch adds a new JS::VM object that houses the JS::Heap. This means that the Heap moves out of Interpreter, and the same Heap can now be used by multiple Interpreters, and can also outlive them. The VM keeps a stack of Interpreter pointers. We push/pop on this stack when entering/exiting execution with a given Interpreter. This allows us to make this change without disturbing too much of the existing code. There is still a 1-to-1 relationship between Interpreter and the global object. This will change in the future. Ultimately, the goal here is to make Interpreter a transient object that only needs to exist while you execute some code. Getting there will take a lot more work though. :^) Note that in LibWeb, the global JS::VM is called main_thread_vm(), to distinguish it from future worker VM's.
2020-09-20 19:24:44 +02:00
namespace JS {
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
class Identifier;
struct BindingPattern;
LibJS: Partially implement resizable ArrayBuffer objects This is (part of) a normative change in the ECMA-262 spec. See: https://github.com/tc39/ecma262/commit/a9ae96e This implements just support for resizing ArrayBuffer objects. This does not implement the SharedArrayBuffer changes, as we do not have enough support to do so.
2023-10-14 19:10:55 -04:00
enum class HandledByHost {
Handled,
Unhandled,
};
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter Taking a big step towards a world of multiple global object, this patch adds a new JS::VM object that houses the JS::Heap. This means that the Heap moves out of Interpreter, and the same Heap can now be used by multiple Interpreters, and can also outlive them. The VM keeps a stack of Interpreter pointers. We push/pop on this stack when entering/exiting execution with a given Interpreter. This allows us to make this change without disturbing too much of the existing code. There is still a 1-to-1 relationship between Interpreter and the global object. This will change in the future. Ultimately, the goal here is to make Interpreter a transient object that only needs to exist while you execute some code. Getting there will take a lot more work though. :^) Note that in LibWeb, the global JS::VM is called main_thread_vm(), to distinguish it from future worker VM's.
2020-09-20 19:24:44 +02:00
class VM : public RefCounted<VM> {
public:
LibJS: Add a way to attach custom data to a JS::VM instance This will be used by LibWeb to attach web engine specific stuff that LibJS doesn't need to know about.
2021-09-08 22:58:36 +02:00
struct CustomData {
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
virtual ~CustomData() = default;
LibJS+LibWeb: Spin event loop via VM::CustomData abstraction Instead of calling Core::EventLoop directly, LibJS now has a virtual function on VM::CustomData for customizing this behavior. We use this in LibWeb to plumb the spin request through to the PlatformEventPlugin.
2022-09-08 00:13:39 +02:00
AK+Userland: Remove NOESCAPE See the next commit for an explanation
2024-05-17 17:09:20 -07:00
virtual void spin_event_loop_until(JS::SafeFunction<bool()> goal_condition) = 0;
LibJS: Add a way to attach custom data to a JS::VM instance This will be used by LibWeb to attach web engine specific stuff that LibJS doesn't need to know about.
2021-09-08 22:58:36 +02:00
};
LibJS: Propagate errors from VM creation
2023-03-17 10:44:47 -04:00
static ErrorOr<NonnullRefPtr<VM>> create(OwnPtr<CustomData> = {});
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();
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter Taking a big step towards a world of multiple global object, this patch adds a new JS::VM object that houses the JS::Heap. This means that the Heap moves out of Interpreter, and the same Heap can now be used by multiple Interpreters, and can also outlive them. The VM keeps a stack of Interpreter pointers. We push/pop on this stack when entering/exiting execution with a given Interpreter. This allows us to make this change without disturbing too much of the existing code. There is still a 1-to-1 relationship between Interpreter and the global object. This will change in the future. Ultimately, the goal here is to make Interpreter a transient object that only needs to exist while you execute some code. Getting there will take a lot more work though. :^) Note that in LibWeb, the global JS::VM is called main_thread_vm(), to distinguish it from future worker VM's.
2020-09-20 19:24:44 +02:00
Heap& heap() { return m_heap; }
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
Heap const& heap() const { return m_heap; }
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter Taking a big step towards a world of multiple global object, this patch adds a new JS::VM object that houses the JS::Heap. This means that the Heap moves out of Interpreter, and the same Heap can now be used by multiple Interpreters, and can also outlive them. The VM keeps a stack of Interpreter pointers. We push/pop on this stack when entering/exiting execution with a given Interpreter. This allows us to make this change without disturbing too much of the existing code. There is still a 1-to-1 relationship between Interpreter and the global object. This will change in the future. Ultimately, the goal here is to make Interpreter a transient object that only needs to exist while you execute some code. Getting there will take a lot more work though. :^) Note that in LibWeb, the global JS::VM is called main_thread_vm(), to distinguish it from future worker VM's.
2020-09-20 19:24:44 +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
Bytecode::Interpreter& bytecode_interpreter();
LibJS: Add VM::dump_backtrace() This is just a simple helper that dumps the current VM call stack to the debug console. I find myself rewriting this function over and over, so let's just have it in the tree.
2021-06-06 22:53:44 +02:00
void dump_backtrace() const;
LibJS: Add source location for Handle nodes in GC graph dumper output With this change JS::Handle root nodes will contain source location where they were constructed like: ``` "94675029575744": { "root": "Handle activate_event_handler \ serenity/Userland/Libraries/LibWeb/DOM/EventTarget.cpp:564", "class_name": "HTMLButtonElement", "edges": [ "94675025955904", "94675026899520", "94675030831168", ```
2023-09-22 02:04:16 +02:00
void gather_roots(HashMap<Cell*, HeapRoot>&);
LibJS: GC should gather roots from all active interpreters If we are in a nested execution context, we shouldn't only mark things used by the active interpreter.
2020-09-21 13:47:33 +02:00
LibJS: Make well-known symbol getters return NonnullGCPtr None of these are ever null after the VM has been initialized, as proved by virtually every caller immediately dereferencing the raw pointer.
2023-04-13 01:14:45 +02:00
#define __JS_ENUMERATE(SymbolName, snake_name) \
NonnullGCPtr<Symbol> well_known_symbol_##snake_name() const \
{ \
return *m_well_known_symbols.snake_name; \
LibJS: Remove GlobalObject from VM::this_value() This is a continuation of the previous six commits. The global object is only needed to return it if the execution context stack is empty, but that doesn't seem like a useful thing to allow in the first place - if you're not currently executing JS, and the execution context stack is empty, there is no this value to retrieve.
2022-08-20 09:48:43 +01:00
}
LibJS: Move well-known symbols to the VM No need to instantiate unique symbols for each Interpreter; they can be VM-global. This reduces the memory cost and startup time anyway.
2020-09-22 16:18:51 +02:00
JS_ENUMERATE_WELL_KNOWN_SYMBOLS
#undef __JS_ENUMERATE
LibJS+LibWeb: Wrap raw JS::Cell*/& fields in GCPtr/NonnullGCPtr
2023-02-26 16:09:02 -07:00
HashMap<String, GCPtr<PrimitiveString>>& string_cache()
LibJS: Add initial support for creating PrimitiveStrings with AK::String This will temporarily bloat the size of PrimitiveString as LibJS is transitioned to use String throughout, but will make doing so piecemeal much easier.
2023-01-13 12:24:02 -05:00
{
return m_string_cache;
}
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
HashMap<ByteString, GCPtr<PrimitiveString>>& byte_string_cache()
LibJS: Move creation of global symbols into Symbol.for() This is now according to the spec. Having a non-standard lookup API that creates symbols on the fly doesn't seem ideal.
2022-12-06 21:06:56 +00: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
return m_byte_string_cache;
LibJS: Move creation of global symbols into Symbol.for() This is now according to the spec. Having a non-standard lookup API that creates symbols on the fly doesn't seem ideal.
2022-12-06 21:06:56 +00:00
}
LibJS: Add initial support for creating PrimitiveStrings with AK::String This will temporarily bloat the size of PrimitiveString as LibJS is transitioned to use String throughout, but will make doing so piecemeal much easier.
2023-01-13 12:24:02 -05:00
LibJS: Cache UTF-16 strings on the VM We were already caching UTF-8 and byte strings, so let's add a cache for UTF-16 strings as well. This is particularly profitable whenever we run regular expressions, since the output of regex execution is a set of UTF-16 strings. Note that this is a weak cache like the other JS string caches, meaning that strings are removed from the cache as they are garbage collected. This avoids billions of PrimitiveString allocations across a run of WPT, significantly reducing GC activity.
2024-10-24 23:02:10 +02:00
HashMap<Utf16String, GCPtr<PrimitiveString>>& utf16_string_cache()
{
return m_utf16_string_cache;
}
LibJS: Let the VM cache an empty ("") PrimitiveString Empty string is extremely common and we can avoid a lot of heap churn by simply caching one in the VM. Primitive strings are immutable anyway so there is no observable behavior change outside of fewer collections.
2020-09-22 16:36:33 +02:00
PrimitiveString& empty_string() { return *m_empty_string; }
LibJS: Add initial support for creating PrimitiveStrings with AK::String This will temporarily bloat the size of PrimitiveString as LibJS is transitioned to use String throughout, but will make doing so piecemeal much easier.
2023-01-13 12:24:02 -05:00
LibJS: Give VM a cache of single-ASCII-character PrimitiveString A large number of JS strings are a single ASCII character. This patch adds a 128-entry cache for those strings to the VM. The cost of the cache is 1536 byte of GC heap (all in same block) + 2304 bytes malloc. This avoids a lot of GC heap allocations, and packing all of these in the same heap block is nice for fragmentation as well.
2020-10-22 17:43:48 +02:00
PrimitiveString& single_ascii_character_string(u8 character)
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(character < 0x80);
LibJS: Give VM a cache of single-ASCII-character PrimitiveString A large number of JS strings are a single ASCII character. This patch adds a 128-entry cache for those strings to the VM. The cost of the cache is 1536 byte of GC heap (all in same block) + 2304 bytes malloc. This avoids a lot of GC heap allocations, and packing all of these in the same heap block is nice for fragmentation as well.
2020-10-22 17:43:48 +02:00
return *m_single_ascii_character_strings[character];
}
LibJS: Let the VM cache an empty ("") PrimitiveString Empty string is extremely common and we can avoid a lot of heap churn by simply caching one in the VM. Primitive strings are immutable anyway so there is no observable behavior change outside of fewer collections.
2020-09-22 16:36:33 +02:00
LibJS: Pre-allocate the out-of-memory error string on the VM If we are out of memory, we can't try to allocate a string that could fail as well. When Error is converted to String, this would result in an endless OOM-throwing loop. Instead, pre-allocate the string on the VM, and use it to construct the Error. Note that as of this commit, the OOM string is still a DeprecatedString. This is just preporatory for Error's conversion to String.
2023-02-16 12:55:22 -05:00
// This represents the list of errors from ErrorTypes.h whose messages are used in contexts which
// must not fail to allocate when they are used. For example, we cannot allocate when we raise an
// out-of-memory error, thus we pre-allocate that error string at VM creation time.
enum class ErrorMessage {
OutOfMemory,
// Keep this last:
__Count,
};
LibJS+Everywhere: Convert JS::Error to String This includes an Error::create overload to create an Error from a UTF-8 StringView. If creating a String from that view fails, the factory will return an OOM InternalError instead. VM::throw_completion can also make use of this overload via its perfect forwarding.
2023-02-16 14:09:11 -05:00
String const& error_message(ErrorMessage) const;
LibJS: Pre-allocate the out-of-memory error string on the VM If we are out of memory, we can't try to allocate a string that could fail as well. When Error is converted to String, this would result in an endless OOM-throwing loop. Instead, pre-allocate the string on the VM, and use it to construct the Error. Note that as of this commit, the OOM string is still a DeprecatedString. This is just preporatory for Error's conversion to String.
2023-02-16 12:55:22 -05:00
LibJS: Prevent stack overflow in flatten_into_array() The check for stack space in VM from push_execution_context has been moved to a method on VM called did_reach_stack_space_limit. This allows us to check the stack size in other places besides push_execution_context. We can now verify that we have enough space on the stack before calling flatten_into_array to ensure that we don't cause a stack overflow error when calling the function with a large depth.
2021-08-13 12:59:57 -04:00
bool did_reach_stack_space_limit() const
{
LibJS: Increase the stack limit on macOS with ASAN enabled The macOS 14 runners on GitHub Actions fail with a stack overflow otherwise.
2024-05-08 10:03:43 -04:00
#if defined(AK_OS_MACOS) && defined(HAS_ADDRESS_SANITIZER)
// We hit stack limits sooner on macOS 14 arm64 with ASAN enabled.
return m_stack_info.size_free() < 96 * KiB;
#else
LibJS: Revert the free stack limit back to 32 KiB
2024-02-20 14:09:26 -05:00
return m_stack_info.size_free() < 32 * KiB;
LibJS: Increase the stack limit on macOS with ASAN enabled The macOS 14 runners on GitHub Actions fail with a stack overflow otherwise.
2024-05-08 10:03:43 -04:00
#endif
LibJS: Prevent stack overflow in flatten_into_array() The check for stack space in VM from push_execution_context has been moved to a method on VM called did_reach_stack_space_limit. This allows us to check the stack size in other places besides push_execution_context. We can now verify that we have enough space on the stack before calling flatten_into_array to ensure that we don't cause a stack overflow error when calling the function with a large depth.
2021-08-13 12:59:57 -04:00
}
LibJS: Replace GlobalObject with VM in remaining AOs [Part 19/19]
2022-08-21 20:38:35 +01:00
// TODO: Rename this function instead of providing a second argument, now that the global object is no longer passed in.
struct CheckStackSpaceLimitTag { };
ThrowCompletionOr<void> push_execution_context(ExecutionContext& context, CheckStackSpaceLimitTag)
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
{
LibJS: Throw RuntimeError when reaching the end of the stack This prevents stack overflows when calling infinite/deep recursive functions, e.g.: const f = () => f(); f(); JSON.stringify({}, () => ({ foo: "bar" })); new Proxy({}, { get: (_, __, p) => p.foo }).foo; The VM caches a StackInfo object to not slow down function calls considerably. VM::push_call_frame() will throw an exception if necessary (plain Error with "RuntimeError" as its .name).
2020-11-08 12:54:52 +00:00
// Ensure we got some stack space left, so the next function call doesn't kill us.
LibJS: Prevent stack overflow in flatten_into_array() The check for stack space in VM from push_execution_context has been moved to a method on VM called did_reach_stack_space_limit. This allows us to check the stack size in other places besides push_execution_context. We can now verify that we have enough space on the stack before calling flatten_into_array to ensure that we don't cause a stack overflow error when calling the function with a large depth.
2021-08-13 12:59:57 -04:00
if (did_reach_stack_space_limit())
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return throw_completion<InternalError>(ErrorType::CallStackSizeExceeded);
LibJS: Only update EC instruction pointer when pushing to EC stack Instead of trying to keep a live reference to the bytecode interpreter's current instruction stream iterator, we now simply copy the current iterator whenever pushing to the ExecutionContext stack. This fixes a stack-use-after-return issue reported by ASAN.
2023-09-02 17:38:17 +02:00
push_execution_context(context);
LibJS: Convert push_execution_context() to ThrowCompletionOr
2021-11-14 12:20:49 +00:00
return {};
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
}
LibJS: Use regular stack for VM call frames instead of Vector storage Keeping the VM call frames in a Vector could cause them to move around underneath us due to Vector resizing. Avoid this issue by allocating CallFrame objects on the stack and having the VM simply keep a list of pointers to each CallFrame, instead of the CallFrames themselves. Fixes #3830. Fixes #3951.
2020-11-07 11:07:17 +01:00
LibJS: Only update EC instruction pointer when pushing to EC stack Instead of trying to keep a live reference to the bytecode interpreter's current instruction stream iterator, we now simply copy the current iterator whenever pushing to the ExecutionContext stack. This fixes a stack-use-after-return issue reported by ASAN.
2023-09-02 17:38:17 +02:00
void push_execution_context(ExecutionContext&);
void pop_execution_context();
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
LibJS: Add spec link and comment to VM::running_execution_context()
2022-12-07 00:12:07 +00:00
// https://tc39.es/ecma262/#running-execution-context
// At any point in time, there is at most one execution context per agent that is actually executing code.
// This is known as the agent's running execution context.
LibJS: Provide better assertion for empty execution context stack When calling `running_execution_context` from other VM APIs, and the execution context stack is empty, the verification message is inlined from AK::Vector. Add a specific VERIFY to `running_execution_context` to help diagnose this issue better.
2023-12-18 17:21:29 -07:00
ExecutionContext& running_execution_context()
{
VERIFY(!m_execution_context_stack.is_empty());
return *m_execution_context_stack.last();
}
ExecutionContext const& running_execution_context() const
{
VERIFY(!m_execution_context_stack.is_empty());
return *m_execution_context_stack.last();
}
LibJS: Add spec link and comment to VM::running_execution_context()
2022-12-07 00:12:07 +00:00
LibJS: Add spec link and comment to VM::execution_context_stack()
2022-12-07 00:12:23 +00:00
// https://tc39.es/ecma262/#execution-context-stack
// The execution context stack is used to track execution contexts.
LibJS: Rename CallFrame => ExecutionContext This struct represents what the ECMAScript specification calls an "execution context" so let's use the same terminology. :^)
2021-06-24 19:17:45 +02:00
Vector<ExecutionContext*> const& execution_context_stack() const { return m_execution_context_stack; }
Vector<ExecutionContext*>& execution_context_stack() { return m_execution_context_stack; }
LibJS: Use regular stack for VM call frames instead of Vector storage Keeping the VM call frames in a Vector could cause them to move around underneath us due to Vector resizing. Avoid this issue by allocating CallFrame objects on the stack and having the VM simply keep a list of pointers to each CallFrame, instead of the CallFrames themselves. Fixes #3830. Fixes #3951.
2020-11-07 11:07:17 +01:00
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
Environment const* lexical_environment() const { return running_execution_context().lexical_environment; }
Environment* lexical_environment() { return running_execution_context().lexical_environment; }
LibJS: Split the per-call-frame environment into lexical and variable To better follow the spec, we need to distinguish between the current execution context's lexical environment and variable environment. This patch moves us to having two record pointers, although both of them point at the same environment records for now.
2021-06-22 15:42:44 +02:00
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
Environment const* variable_environment() const { return running_execution_context().variable_environment; }
Environment* variable_environment() { return running_execution_context().variable_environment; }
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
LibJS: Prepare ExecutionContext to store the current Realm Record Also add VM::current_realm() to retrieve it, similar to all the other getters (running_execution_context() et al.).
2021-09-11 20:55:11 +01:00
// https://tc39.es/ecma262/#current-realm
// The value of the Realm component of the running execution context is also called the current Realm Record.
Realm const* current_realm() const { return running_execution_context().realm; }
Realm* current_realm() { return running_execution_context().realm; }
LibJS: Add VM::active_function_object()
2022-01-15 00:30:52 +01:00
// https://tc39.es/ecma262/#active-function-object
// The value of the Function component of the running execution context is also called the active function object.
FunctionObject const* active_function_object() const { return running_execution_context().function; }
FunctionObject* active_function_object() { return running_execution_context().function; }
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
bool in_strict_mode() const;
size_t argument_count() const
{
LibJS: Rename CallFrame => ExecutionContext This struct represents what the ECMAScript specification calls an "execution context" so let's use the same terminology. :^)
2021-06-24 19:17:45 +02:00
if (m_execution_context_stack.is_empty())
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
return 0;
LibJS: Rename CallFrame => ExecutionContext This struct represents what the ECMAScript specification calls an "execution context" so let's use the same terminology. :^)
2021-06-24 19:17:45 +02:00
return running_execution_context().arguments.size();
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
}
Value argument(size_t index) const
{
LibJS: Rename CallFrame => ExecutionContext This struct represents what the ECMAScript specification calls an "execution context" so let's use the same terminology. :^)
2021-06-24 19:17:45 +02:00
if (m_execution_context_stack.is_empty())
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
return {};
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
return running_execution_context().argument(index);
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
}
LibJS: Remove GlobalObject from VM::this_value() This is a continuation of the previous six commits. The global object is only needed to return it if the execution context stack is empty, but that doesn't seem like a useful thing to allow in the first place - if you're not currently executing JS, and the execution context stack is empty, there is no this value to retrieve.
2022-08-20 09:48:43 +01:00
Value this_value() const
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
{
LibJS: Rename CallFrame => ExecutionContext This struct represents what the ECMAScript specification calls an "execution context" so let's use the same terminology. :^)
2021-06-24 19:17:45 +02:00
return running_execution_context().this_value;
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
}
LibJS: Replace GlobalObject with VM in Environment AOs [Part 5/19]
2022-08-21 15:12:43 +01:00
ThrowCompletionOr<Value> resolve_this_binding();
LibJS: Evaluate `this` in terms of ResolveThisBinding
2021-06-25 11:40:03 +02:00
Everywhere: Remove needless trailing semi-colons after functions This is a new option in clang-format-16.
2023-07-07 22:48:11 -04:00
StackInfo const& stack_info() const { return m_stack_info; }
LibJS+AK: Move cross-platform stack bounds code from JS::Heap to AK::StackInfo This will be useful for other things than the Heap, maybe even outside of LibJS.
2020-11-08 12:48:16 +00:00
LibJS: Port Symbol to String This includes the VM's global_symbol_registry HashMap, which can now store String keys.
2023-02-11 16:14:41 +00:00
HashMap<String, NonnullGCPtr<Symbol>> const& global_symbol_registry() const { return m_global_symbol_registry; }
HashMap<String, NonnullGCPtr<Symbol>>& global_symbol_registry() { return m_global_symbol_registry; }
LibJS: Add const/non-const VM::global_symbol_registry() getters This will allow us to replace the strange get_global_symbol() API that creates symbols on the fly when not found.
2022-12-06 21:02:06 +00:00
LibJS: Store and maintain an "execution generation" counter This counter is increased each time a synchronous execution sequence completes, and will allow us to emulate the abstract operations AddToKeptObjects & ClearKeptObjects efficiently.
2021-06-12 17:32:54 +03:00
u32 execution_generation() const { return m_execution_generation; }
void finish_execution_generation() { ++m_execution_generation; }
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
ThrowCompletionOr<Reference> resolve_binding(DeprecatedFlyString const&, Environment* = nullptr);
ThrowCompletionOr<Reference> get_identifier_reference(Environment*, DeprecatedFlyString, bool strict, size_t hops = 0);
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
// 5.2.3.2 Throw an Exception, https://tc39.es/ecma262/#sec-throw-an-exception
template<typename T, typename... Args>
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
Completion throw_completion(Args&&... args)
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
{
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
auto& realm = *current_realm();
LibJS+Everywhere: Convert JS::Error to String This includes an Error::create overload to create an Error from a UTF-8 StringView. If creating a String from that view fails, the factory will return an OOM InternalError instead. VM::throw_completion can also make use of this overload via its perfect forwarding.
2023-02-16 14:09:11 -05:00
auto completion = T::create(realm, forward<Args>(args)...);
LibJS: Stop propagating small OOM errors from the Error object
2023-09-06 08:18:01 -04:00
return JS::throw_completion(completion);
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
}
LibJS: Create exception messages as Strings The JS::Error types all store their exception messages as a String. So by using ByteString, we hit the StringView constructor, and end up allocating the same string twice.
2024-07-17 09:55:20 -04:00
template<typename T>
Completion throw_completion(ErrorType type)
{
return throw_completion<T>(String::from_utf8_without_validation(type.message().bytes()));
}
LibJS: Add VM::throw_completion helper for throwing custom Strings
2021-09-21 22:08:38 +03:00
template<typename T, typename... Args>
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
Completion throw_completion(ErrorType type, Args&&... args)
LibJS: Add VM::throw_completion helper for throwing custom Strings
2021-09-21 22:08:38 +03:00
{
LibJS: Create exception messages as Strings The JS::Error types all store their exception messages as a String. So by using ByteString, we hit the StringView constructor, and end up allocating the same string twice.
2024-07-17 09:55:20 -04:00
return throw_completion<T>(MUST(String::formatted(type.message(), forward<Args>(args)...)));
LibJS: Add VM::throw_completion helper for throwing custom Strings
2021-09-21 22:08:38 +03:00
}
LibJS: Bring function environment records closer to the spec This patch adds FunctionEnvironmentRecord as a subclass of the existing DeclarativeEnvironmentRecord. Things that are specific to function environment records move into there, simplifying the base. Most of the abstract operations related to function environment records are rewritten to match the spec exactly. I also had to implement GetThisEnvironment() and GetSuperConstructor() to keep tests working after the changes, so that's nice as well. :^)
2021-06-22 13:30:48 +02:00
Value get_new_target();
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
LibJS: Implement import.meta for bytecode
2023-07-11 23:07:12 -04:00
Object* get_import_meta();
LibJS+LibWeb: Let Realm store a plain Object for [[GlobalObject]] This removes the requirement of having a global object that actually inherits from JS::GlobalObject, which is now a perfectly valid scenario. With the upcoming removal of wrapper objects in LibWeb, the HTML::Window object will inherit from DOM::EventTarget, which means it cannot also inherit from JS::GlobalObject.
2022-08-28 15:03:45 +01:00
Object& get_global_object();
LibJS: Replace GlobalObject with VM in Reference AOs [Part 6/19]
2022-08-21 15:39:13 +01:00
LibJS: Cache commonly used FlyStrings in the VM Roughly 7% of test-js runtime was spent creating FlyStrings from string literals. This patch frontloads that work and caches all the commonly used names in LibJS on a CommonPropertyNames struct that hangs off VM.
2020-10-13 23:49:19 +02:00
CommonPropertyNames names;
LibJS: Make `typeof` a lot faster by caching all possible results The typeof operator has a very small set of possible resulting strings, so let's make it much faster by caching those strings on the VM. ~8x speed-up on this microbenchmark: for (let i = 0; i < 10_000_000; ++i) { typeof i; }
2024-07-23 09:42:00 +02:00
struct {
GCPtr<PrimitiveString> number;
GCPtr<PrimitiveString> undefined;
GCPtr<PrimitiveString> object;
GCPtr<PrimitiveString> string;
GCPtr<PrimitiveString> symbol;
GCPtr<PrimitiveString> boolean;
GCPtr<PrimitiveString> bigint;
GCPtr<PrimitiveString> function;
} typeof_strings;
LibJS: Cache commonly used FlyStrings in the VM Roughly 7% of test-js runtime was spent creating FlyStrings from string literals. This patch frontloads that work and caches all the commonly used names in LibJS on a CommonPropertyNames struct that hangs off VM.
2020-10-13 23:49:19 +02:00
LibJS: Add initial support for Promises Almost a year after first working on this, it's finally done: an implementation of Promises for LibJS! :^) The core functionality is working and closely following the spec [1]. I mostly took the pseudo code and transformed it into C++ - if you read and understand it, you will know how the spec implements Promises; and if you read the spec first, the code will look very familiar. Implemented functions are: - Promise() constructor - Promise.prototype.then() - Promise.prototype.catch() - Promise.prototype.finally() - Promise.resolve() - Promise.reject() For the tests I added a new function to test-js's global object, runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs(). By design, queued jobs normally only run after the script was fully executed, making it improssible to test handlers in individual test() calls by default [2]. Subsequent commits include integrations into LibWeb and js(1) - pretty-printing, running queued promise jobs when necessary. This has an unusual amount of dbgln() statements, all hidden behind the PROMISE_DEBUG flag - I'm leaving them in for now as they've been very useful while debugging this, things can get quite complex with so many asynchronously executed functions. I've not extensively explored use of these APIs for promise-based functionality in LibWeb (fetch(), Notification.requestPermission() etc.), but we'll get there in due time. [1]: https://tc39.es/ecma262/#sec-promise-objects [2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues
2021-04-01 22:13:29 +02:00
void run_queued_promise_jobs();
LibJS: Make PromiseJob store callback as a HeapFunction This is a speculative fix for a flake seen on CI where a JobCallback captured by a PromiseJob callback was GC'd prematurely.
2024-03-25 14:18:22 +01:00
void enqueue_promise_job(NonnullGCPtr<HeapFunction<ThrowCompletionOr<Value>()>> job, Realm*);
LibJS: Add initial support for Promises Almost a year after first working on this, it's finally done: an implementation of Promises for LibJS! :^) The core functionality is working and closely following the spec [1]. I mostly took the pseudo code and transformed it into C++ - if you read and understand it, you will know how the spec implements Promises; and if you read the spec first, the code will look very familiar. Implemented functions are: - Promise() constructor - Promise.prototype.then() - Promise.prototype.catch() - Promise.prototype.finally() - Promise.resolve() - Promise.reject() For the tests I added a new function to test-js's global object, runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs(). By design, queued jobs normally only run after the script was fully executed, making it improssible to test handlers in individual test() calls by default [2]. Subsequent commits include integrations into LibWeb and js(1) - pretty-printing, running queued promise jobs when necessary. This has an unusual amount of dbgln() statements, all hidden behind the PROMISE_DEBUG flag - I'm leaving them in for now as they've been very useful while debugging this, things can get quite complex with so many asynchronously executed functions. I've not extensively explored use of these APIs for promise-based functionality in LibWeb (fetch(), Notification.requestPermission() etc.), but we'll get there in due time. [1]: https://tc39.es/ecma262/#sec-promise-objects [2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues
2021-04-01 22:13:29 +02:00
LibJS: Add the FinalizationRegistry built-in object As well as the needed functionality in VM to enqueue and run cleanup jobs for the FinalizationRegistry instances.
2021-06-15 22:16:17 +03:00
void run_queued_finalization_registry_cleanup_jobs();
void enqueue_finalization_registry_cleanup_job(FinalizationRegistry&);
LibJS: Setup host hooks and have promise jobs work out the realm This allows the host of LibJS (notably LibWeb in this case) to override certain functions such as HostEnqueuePromiseJob, so it can do it's own thing in certain situations. Notably, LibWeb will override HostEnqueuePromiseJob to put promise jobs on the microtask queue. This also makes promise jobs use AK::Function instead of JS::NativeFunction. This removes the need to go through a JavaScript function and it more closely matches the spec's idea of "abstract closures"
2022-02-06 03:46:45 +00:00
void promise_rejection_tracker(Promise&, Promise::RejectionOperation) const;
LibJS: Add initial support for Promises Almost a year after first working on this, it's finally done: an implementation of Promises for LibJS! :^) The core functionality is working and closely following the spec [1]. I mostly took the pseudo code and transformed it into C++ - if you read and understand it, you will know how the spec implements Promises; and if you read the spec first, the code will look very familiar. Implemented functions are: - Promise() constructor - Promise.prototype.then() - Promise.prototype.catch() - Promise.prototype.finally() - Promise.resolve() - Promise.reject() For the tests I added a new function to test-js's global object, runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs(). By design, queued jobs normally only run after the script was fully executed, making it improssible to test handlers in individual test() calls by default [2]. Subsequent commits include integrations into LibWeb and js(1) - pretty-printing, running queued promise jobs when necessary. This has an unusual amount of dbgln() statements, all hidden behind the PROMISE_DEBUG flag - I'm leaving them in for now as they've been very useful while debugging this, things can get quite complex with so many asynchronously executed functions. I've not extensively explored use of these APIs for promise-based functionality in LibWeb (fetch(), Notification.requestPermission() etc.), but we'll get there in due time. [1]: https://tc39.es/ecma262/#sec-promise-objects [2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues
2021-04-01 22:13:29 +02:00
LibJS: Stop qualifying AK::Function Now that JS function objects are JS::FunctionObject, we can stop qualifying AK::Function and just say "Function" everywhere. Nice. :^)
2021-06-27 22:38:42 +02:00
Function<void()> on_call_stack_emptied;
LibJS: Setup host hooks and have promise jobs work out the realm This allows the host of LibJS (notably LibWeb in this case) to override certain functions such as HostEnqueuePromiseJob, so it can do it's own thing in certain situations. Notably, LibWeb will override HostEnqueuePromiseJob to put promise jobs on the microtask queue. This also makes promise jobs use AK::Function instead of JS::NativeFunction. This removes the need to go through a JavaScript function and it more closely matches the spec's idea of "abstract closures"
2022-02-06 03:46:45 +00:00
Function<void(Promise&)> on_promise_unhandled_rejection;
Function<void(Promise&)> on_promise_rejection_handled;
LibJS: Add the [[Unimplemented]] attribute Properties marked with the [[Unimplemented]] attribute behave as normal but invoke the `VM::on_unimplemented_property_access callback` when they are accessed.
2024-06-11 07:07:07 +01:00
Function<void(Object const&, PropertyKey const&)> on_unimplemented_property_access;
LibJS: Add initial support for Promises Almost a year after first working on this, it's finally done: an implementation of Promises for LibJS! :^) The core functionality is working and closely following the spec [1]. I mostly took the pseudo code and transformed it into C++ - if you read and understand it, you will know how the spec implements Promises; and if you read the spec first, the code will look very familiar. Implemented functions are: - Promise() constructor - Promise.prototype.then() - Promise.prototype.catch() - Promise.prototype.finally() - Promise.resolve() - Promise.reject() For the tests I added a new function to test-js's global object, runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs(). By design, queued jobs normally only run after the script was fully executed, making it improssible to test handlers in individual test() calls by default [2]. Subsequent commits include integrations into LibWeb and js(1) - pretty-printing, running queued promise jobs when necessary. This has an unusual amount of dbgln() statements, all hidden behind the PROMISE_DEBUG flag - I'm leaving them in for now as they've been very useful while debugging this, things can get quite complex with so many asynchronously executed functions. I've not extensively explored use of these APIs for promise-based functionality in LibWeb (fetch(), Notification.requestPermission() etc.), but we'll get there in due time. [1]: https://tc39.es/ecma262/#sec-promise-objects [2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues
2021-04-01 22:13:29 +02:00
LibJS: Add a way to attach custom data to a JS::VM instance This will be used by LibWeb to attach web engine specific stuff that LibJS doesn't need to know about.
2021-09-08 22:58:36 +02:00
CustomData* custom_data() { return m_custom_data; }
LibJS: Add a way to save/restore the entire execution context stack This will be used by LibWeb to squirrel away the stack while performing a microtask checkpoint in some cases. VM will simply consider saved execution context stacks as GC roots as well.
2021-10-03 14:52:53 +02:00
void save_execution_context_stack();
LibJS: Add method to VM to clear the execution context stack This is needed for the spin the event loop AO in LibWeb
2024-01-18 12:49:35 -07:00
void clear_execution_context_stack();
LibJS: Add a way to save/restore the entire execution context stack This will be used by LibWeb to squirrel away the stack while performing a microtask checkpoint in some cases. VM will simply consider saved execution context stacks as GC roots as well.
2021-10-03 14:52:53 +02:00
void restore_execution_context_stack();
LibJS: Implement HostResolveImportedModule for LibJS This loads modules with relative paths from the referencing module. In this commit the only way to run a module is via the interpreter which can link and evaluate a module (and all its dependencies).
2022-01-19 01:22:58 +01:00
// Do not call this method unless you are sure this is the only and first module to be loaded in this vm.
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<void> link_and_eval_module(Badge<Bytecode::Interpreter>, SourceTextModule& module);
LibJS: Implement HostResolveImportedModule for LibJS This loads modules with relative paths from the referencing module. In this commit the only way to run a module is via the interpreter which can link and evaluate a module (and all its dependencies).
2022-01-19 01:22:58 +01:00
LibJS: Add ScriptOrModule to execution context and track it everywhere
2022-01-17 14:48:22 +01:00
ScriptOrModule get_active_script_or_module() const;
LibJS+LibWeb: Bring script fetching closer to the spec This patch updates various parts of the script fetching implementation to match the current specification. Notably, the implementation of changes to the import assertions / attributes proposal are not part of this patch(series).
2023-10-29 02:53:53 +01:00
// NOTE: The host defined implementation described in the web spec https://html.spec.whatwg.org/multipage/webappapis.html#hostloadimportedmodule
// currently references proposal-import-attributes.
// Our implementation of this proposal is outdated however, as such we try to adapt the proposal and living standard
// to match our implementation for now.
// 16.2.1.8 HostLoadImportedModule ( referrer, moduleRequest, hostDefined, payload ), https://tc39.es/proposal-import-attributes/#sec-HostLoadImportedModule
LibJS+LibWeb: More bringing module loading closer to spec In particular, this patch removes three host hooks on JS::VM in favor of the new JS-side module loading stuff.
2023-12-02 22:56:47 +01:00
Function<void(ImportedModuleReferrer, ModuleRequest const&, GCPtr<GraphLoadingState::HostDefined>, ImportedModulePayload)> host_load_imported_module;
LibJS: Add host layering point related to modules to VM Also make HostResolveImportedModule fail on the browser to prevent module loading for now.
2022-01-18 19:14:25 +01:00
LibJS: Provide a mutable SourceTextModule to HostGetImportMetaProperties The Web host, for example, will need mutable references to objects owned by the SourceTextModule.
2023-07-17 21:15:55 -04:00
Function<HashMap<PropertyKey, Value>(SourceTextModule&)> host_get_import_meta_properties;
LibJS: Add host layering point related to modules to VM Also make HostResolveImportedModule fail on the browser to prevent module loading for now.
2022-01-18 19:14:25 +01:00
Function<void(Object*, SourceTextModule const&)> host_finalize_import_meta;
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
Function<Vector<ByteString>()> host_get_supported_import_attributes;
LibJS: Implement the import assertions proposal The hard part of parsing them in import statements and calls was already done so this is just removing some check which threw before on assertions. And filtering the assertions based on the result of a new host hook.
2022-01-27 02:44:03 +01:00
LibJS+LibWeb: More bringing module loading closer to spec In particular, this patch removes three host hooks on JS::VM in favor of the new JS-side module loading stuff.
2023-12-02 22:56:47 +01:00
void set_dynamic_imports_allowed(bool value) { m_dynamic_imports_allowed = value; }
LibJS: Implement ImportCall and HostImportModuleDynamically This allows us to load modules from scripts. This can be dangerous as it can load arbitrary files. Because of that it fails and throws by default. Currently, only js and JavaScriptTestRunner enable the default hook. This also adds tests to test-js which test module code. Because we form a spec perspective can't "enter" a module this is the easiest way to run tests without having to modify test-js to have special cases for modules. To specify modules in test-js we use the extension '.mjs' this is to ensure the files are not executed. We do still want to lint these files so the prettier scripts have changed to look for '.mjs' files as well.
2022-01-18 19:39:36 +01:00
LibJS: Setup host hooks and have promise jobs work out the realm This allows the host of LibJS (notably LibWeb in this case) to override certain functions such as HostEnqueuePromiseJob, so it can do it's own thing in certain situations. Notably, LibWeb will override HostEnqueuePromiseJob to put promise jobs on the microtask queue. This also makes promise jobs use AK::Function instead of JS::NativeFunction. This removes the need to go through a JavaScript function and it more closely matches the spec's idea of "abstract closures"
2022-02-06 03:46:45 +00:00
Function<void(Promise&, Promise::RejectionOperation)> host_promise_rejection_tracker;
LibJS: Pass call/construct argument lists as ReadonlySpan<Value> (Instead of MarkedVector<Value>.) This is a step towards not storing argument lists in MarkedVector<Value> at all. Note that they still end up in MarkedVectors since that's what ExecutionContext has.
2023-11-27 12:56:20 +01:00
Function<ThrowCompletionOr<Value>(JobCallback&, Value, ReadonlySpan<Value>)> host_call_job_callback;
LibJS: Setup host hooks and have promise jobs work out the realm This allows the host of LibJS (notably LibWeb in this case) to override certain functions such as HostEnqueuePromiseJob, so it can do it's own thing in certain situations. Notably, LibWeb will override HostEnqueuePromiseJob to put promise jobs on the microtask queue. This also makes promise jobs use AK::Function instead of JS::NativeFunction. This removes the need to go through a JavaScript function and it more closely matches the spec's idea of "abstract closures"
2022-02-06 03:46:45 +00:00
Function<void(FinalizationRegistry&)> host_enqueue_finalization_registry_cleanup_job;
LibJS: Make PromiseJob store callback as a HeapFunction This is a speculative fix for a flake seen on CI where a JobCallback captured by a PromiseJob callback was GC'd prematurely.
2024-03-25 14:18:22 +01:00
Function<void(NonnullGCPtr<HeapFunction<ThrowCompletionOr<Value>()>>, Realm*)> host_enqueue_promise_job;
LibJS+LibWeb: Change JobCallback to be GC-allocated Fixes leak caused by mutual dependency when JS::Handle<JobCallback> is owned by GC-allocated PromiseReaction.
2024-03-12 03:49:13 +01:00
Function<JS::NonnullGCPtr<JobCallback>(FunctionObject&)> host_make_job_callback;
LibJS: Remove callerRealm from HostEnsureCanCompileStrings This is a normative change in the ecma262 spec. See: https://github.com/tc39/ecma262/commit/2527be4
2022-04-22 19:10:27 +01:00
Function<ThrowCompletionOr<void>(Realm&)> host_ensure_can_compile_strings;
LibJS: Add the HostEnsureCanAddPrivateElement hook This hook allows us to reject private elements on certain exotic objects like the window object in browser. Note that per the spec we should only call this hook if the host is a web browser, however because LibJS has no way of knowing whether it is in a web browser environment we just always call the host hook.
2022-08-14 00:51:32 +02:00
Function<ThrowCompletionOr<void>(Object&)> host_ensure_can_add_private_element;
LibJS: Partially implement resizable ArrayBuffer objects This is (part of) a normative change in the ECMA-262 spec. See: https://github.com/tc39/ecma262/commit/a9ae96e This implements just support for resizing ArrayBuffer objects. This does not implement the SharedArrayBuffer changes, as we do not have enough support to do so.
2023-10-14 19:10:55 -04:00
Function<ThrowCompletionOr<HandledByHost>(ArrayBuffer&, size_t)> host_resize_array_buffer;
LibJS+LibWeb: Add a custom host hook to log unparsed date strings This lets us log when our Date.parse implementation was unable to handle a string found on the web.
2024-09-08 11:15:07 -04:00
Function<void(StringView)> host_unrecognized_date_string;
LibJS: Allow host to create ShadowRealm global object This implements the proposed update to the ShadowRealm proposal for integrating the ShadowRealm specification into the web platform.
2024-10-23 18:15:19 +13:00
Function<ThrowCompletionOr<NonnullGCPtr<ShadowRealm>>(Realm&, NonnullOwnPtr<ExecutionContext>, ShadowRealm&)> host_initialize_shadow_realm;
LibJS: Setup host hooks and have promise jobs work out the realm This allows the host of LibJS (notably LibWeb in this case) to override certain functions such as HostEnqueuePromiseJob, so it can do it's own thing in certain situations. Notably, LibWeb will override HostEnqueuePromiseJob to put promise jobs on the microtask queue. This also makes promise jobs use AK::Function instead of JS::NativeFunction. This removes the need to go through a JavaScript function and it more closely matches the spec's idea of "abstract closures"
2022-02-06 03:46:45 +00:00
LibJS: Lazily collect stack trace information The previous implementation was calling `backtrace()` for every function call, which is quite slow. Instead, this implementation provides VM::stack_trace() which unwinds the native stack, maps it through NativeExecutable::get_source_range and combines it with source ranges from interpreted call frames.
2023-11-01 00:39:28 +01:00
Vector<StackTraceElement> stack_trace() const;
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter Taking a big step towards a world of multiple global object, this patch adds a new JS::VM object that houses the JS::Heap. This means that the Heap moves out of Interpreter, and the same Heap can now be used by multiple Interpreters, and can also outlive them. The VM keeps a stack of Interpreter pointers. We push/pop on this stack when entering/exiting execution with a given Interpreter. This allows us to make this change without disturbing too much of the existing code. There is still a 1-to-1 relationship between Interpreter and the global object. This will change in the future. Ultimately, the goal here is to make Interpreter a transient object that only needs to exist while you execute some code. Getting there will take a lot more work though. :^) Note that in LibWeb, the global JS::VM is called main_thread_vm(), to distinguish it from future worker VM's.
2020-09-20 19:24:44 +02:00
private:
LibJS: Move creation of fallible VM objects to its creation factory No change of behavior in this patch, but this will allow this factory to propagate any errors from the creation of these objects.
2023-03-17 10:21:51 -04:00
using ErrorMessages = AK::Array<String, to_underlying(ErrorMessage::__Count)>;
struct WellKnownSymbols {
#define __JS_ENUMERATE(SymbolName, snake_name) \
GCPtr<Symbol> snake_name;
JS_ENUMERATE_WELL_KNOWN_SYMBOLS
#undef __JS_ENUMERATE
};
VM(OwnPtr<CustomData>, ErrorMessages);
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter Taking a big step towards a world of multiple global object, this patch adds a new JS::VM object that houses the JS::Heap. This means that the Heap moves out of Interpreter, and the same Heap can now be used by multiple Interpreters, and can also outlive them. The VM keeps a stack of Interpreter pointers. We push/pop on this stack when entering/exiting execution with a given Interpreter. This allows us to make this change without disturbing too much of the existing code. There is still a 1-to-1 relationship between Interpreter and the global object. This will change in the future. Ultimately, the goal here is to make Interpreter a transient object that only needs to exist while you execute some code. Getting there will take a lot more work though. :^) Note that in LibWeb, the global JS::VM is called main_thread_vm(), to distinguish it from future worker VM's.
2020-09-20 19:24:44 +02:00
LibJS+LibWeb: More bringing module loading closer to spec In particular, this patch removes three host hooks on JS::VM in favor of the new JS-side module loading stuff.
2023-12-02 22:56:47 +01:00
void load_imported_module(ImportedModuleReferrer, ModuleRequest const&, GCPtr<GraphLoadingState::HostDefined>, ImportedModulePayload);
LibJS: Use LoadRequestedModules in the ad-hoc module loading path This ensures that modules go through the expected state transitions, fixing hundreds of test262 tests.
2023-12-06 11:14:41 +01:00
ThrowCompletionOr<void> link_and_eval_module(CyclicModule&);
LibJS: Implement HostResolveImportedModule for LibJS This loads modules with relative paths from the referencing module. In this commit the only way to run a module is via the interpreter which can link and evaluate a module (and all its dependencies).
2022-01-19 01:22:58 +01:00
LibJS: Move creation of fallible VM objects to its creation factory No change of behavior in this patch, but this will allow this factory to propagate any errors from the creation of these objects.
2023-03-17 10:21:51 -04:00
void set_well_known_symbols(WellKnownSymbols well_known_symbols) { m_well_known_symbols = move(well_known_symbols); }
LibJS+LibWeb: Wrap raw JS::Cell*/& fields in GCPtr/NonnullGCPtr
2023-02-26 16:09:02 -07:00
HashMap<String, GCPtr<PrimitiveString>> m_string_cache;
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
HashMap<ByteString, GCPtr<PrimitiveString>> m_byte_string_cache;
LibJS: Cache UTF-16 strings on the VM We were already caching UTF-8 and byte strings, so let's add a cache for UTF-16 strings as well. This is particularly profitable whenever we run regular expressions, since the output of regex execution is a set of UTF-16 strings. Note that this is a weak cache like the other JS string caches, meaning that strings are removed from the cache as they are garbage collected. This avoids billions of PrimitiveString allocations across a run of WPT, significantly reducing GC activity.
2024-10-24 23:02:10 +02:00
HashMap<Utf16String, GCPtr<PrimitiveString>> m_utf16_string_cache;
LibJS: Keep track of PrimitiveStrings and share them VM now has a string cache which tracks all live PrimitiveStrings and reuses an existing one if possible. This drastically reduces the number of GC-allocated strings in many real-word situations.
2021-10-02 01:36:57 +02:00
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter Taking a big step towards a world of multiple global object, this patch adds a new JS::VM object that houses the JS::Heap. This means that the Heap moves out of Interpreter, and the same Heap can now be used by multiple Interpreters, and can also outlive them. The VM keeps a stack of Interpreter pointers. We push/pop on this stack when entering/exiting execution with a given Interpreter. This allows us to make this change without disturbing too much of the existing code. There is still a 1-to-1 relationship between Interpreter and the global object. This will change in the future. Ultimately, the goal here is to make Interpreter a transient object that only needs to exist while you execute some code. Getting there will take a lot more work though. :^) Note that in LibWeb, the global JS::VM is called main_thread_vm(), to distinguish it from future worker VM's.
2020-09-20 19:24:44 +02:00
Heap m_heap;
LibJS: Move well-known symbols to the VM No need to instantiate unique symbols for each Interpreter; they can be VM-global. This reduces the memory cost and startup time anyway.
2020-09-22 16:18:51 +02:00
LibJS: Rename CallFrame => ExecutionContext This struct represents what the ECMAScript specification calls an "execution context" so let's use the same terminology. :^)
2021-06-24 19:17:45 +02:00
Vector<ExecutionContext*> m_execution_context_stack;
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
LibJS: Add a way to save/restore the entire execution context stack This will be used by LibWeb to squirrel away the stack while performing a microtask checkpoint in some cases. VM will simply consider saved execution context stacks as GC roots as well.
2021-10-03 14:52:53 +02:00
Vector<Vector<ExecutionContext*>> m_saved_execution_context_stacks;
LibJS+AK: Move cross-platform stack bounds code from JS::Heap to AK::StackInfo This will be useful for other things than the Heap, maybe even outside of LibJS.
2020-11-08 12:48:16 +00:00
StackInfo m_stack_info;
LibJS: Rename m_global_symbol_map to m_global_symbol_registry The spec calls it "GlobalSymbolRegistry".
2022-12-06 20:58:15 +00:00
// GlobalSymbolRegistry, https://tc39.es/ecma262/#table-globalsymbolregistry-record-fields
LibJS: Port Symbol to String This includes the VM's global_symbol_registry HashMap, which can now store String keys.
2023-02-11 16:14:41 +00:00
HashMap<String, NonnullGCPtr<Symbol>> m_global_symbol_registry;
LibJS: Move well-known symbols to the VM No need to instantiate unique symbols for each Interpreter; they can be VM-global. This reduces the memory cost and startup time anyway.
2020-09-22 16:18:51 +02:00
LibJS: Make PromiseJob store callback as a HeapFunction This is a speculative fix for a flake seen on CI where a JobCallback captured by a PromiseJob callback was GC'd prematurely.
2024-03-25 14:18:22 +01:00
Vector<NonnullGCPtr<HeapFunction<ThrowCompletionOr<Value>()>>> m_promise_jobs;
LibJS: Add initial support for Promises Almost a year after first working on this, it's finally done: an implementation of Promises for LibJS! :^) The core functionality is working and closely following the spec [1]. I mostly took the pseudo code and transformed it into C++ - if you read and understand it, you will know how the spec implements Promises; and if you read the spec first, the code will look very familiar. Implemented functions are: - Promise() constructor - Promise.prototype.then() - Promise.prototype.catch() - Promise.prototype.finally() - Promise.resolve() - Promise.reject() For the tests I added a new function to test-js's global object, runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs(). By design, queued jobs normally only run after the script was fully executed, making it improssible to test handlers in individual test() calls by default [2]. Subsequent commits include integrations into LibWeb and js(1) - pretty-printing, running queued promise jobs when necessary. This has an unusual amount of dbgln() statements, all hidden behind the PROMISE_DEBUG flag - I'm leaving them in for now as they've been very useful while debugging this, things can get quite complex with so many asynchronously executed functions. I've not extensively explored use of these APIs for promise-based functionality in LibWeb (fetch(), Notification.requestPermission() etc.), but we'll get there in due time. [1]: https://tc39.es/ecma262/#sec-promise-objects [2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues
2021-04-01 22:13:29 +02:00
LibJS+LibWeb: Wrap raw JS::Cell*/& fields in GCPtr/NonnullGCPtr
2023-02-26 16:09:02 -07:00
Vector<GCPtr<FinalizationRegistry>> m_finalization_registry_cleanup_jobs;
LibJS: Add the FinalizationRegistry built-in object As well as the needed functionality in VM to enqueue and run cleanup jobs for the FinalizationRegistry instances.
2021-06-15 22:16:17 +03:00
LibJS+LibWeb: Wrap raw JS::Cell*/& fields in GCPtr/NonnullGCPtr
2023-02-26 16:09:02 -07:00
GCPtr<PrimitiveString> m_empty_string;
GCPtr<PrimitiveString> m_single_ascii_character_strings[128] {};
LibJS: Move creation of fallible VM objects to its creation factory No change of behavior in this patch, but this will allow this factory to propagate any errors from the creation of these objects.
2023-03-17 10:21:51 -04:00
ErrorMessages m_error_messages;
LibJS: Implement HostResolveImportedModule for LibJS This loads modules with relative paths from the referencing module. In this commit the only way to run a module is via the interpreter which can link and evaluate a module (and all its dependencies).
2022-01-19 01:22:58 +01:00
struct StoredModule {
LibJS+LibWeb: Another round of bringing module loading closer to spec In particular, this patch focuses on: - Updating the old "import assertions" to the new "import attributes" - Allowing realms as module import referrer
2023-12-02 16:20:01 +01:00
ImportedModuleReferrer referrer;
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
ByteString filename;
ByteString type;
LibJS: Make Script and Module GC-allocated This ensures that code currently in any active or saved execution stack always stays alive.
2022-09-05 14:31:25 +02:00
Handle<Module> module;
LibJS: Implement HostResolveImportedModule for LibJS This loads modules with relative paths from the referencing module. In this commit the only way to run a module is via the interpreter which can link and evaluate a module (and all its dependencies).
2022-01-19 01:22:58 +01:00
bool has_once_started_linking { false };
};
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
StoredModule* get_stored_module(ImportedModuleReferrer const& script_or_module, ByteString const& filename, ByteString const& type);
LibJS: Implement HostResolveImportedModule for LibJS This loads modules with relative paths from the referencing module. In this commit the only way to run a module is via the interpreter which can link and evaluate a module (and all its dependencies).
2022-01-19 01:22:58 +01:00
Vector<StoredModule> m_loaded_modules;
LibJS: Let the VM cache an empty ("") PrimitiveString Empty string is extremely common and we can avoid a lot of heap churn by simply caching one in the VM. Primitive strings are immutable anyway so there is no observable behavior change outside of fewer collections.
2020-09-22 16:36:33 +02:00
LibJS: Move creation of fallible VM objects to its creation factory No change of behavior in this patch, but this will allow this factory to propagate any errors from the creation of these objects.
2023-03-17 10:21:51 -04:00
WellKnownSymbols m_well_known_symbols;
LibJS: Add a scope object abstraction Both GlobalObject and LexicalEnvironment now inherit from ScopeObject, and the VM's call frames point to a ScopeObject chain rather than just a LexicalEnvironment chain. This gives us much more flexibility to implement things like "with", and also unifies some of the code paths that previously required special handling of the global object. There's a bunch of more cleanup that can be done in the wake of this change, and there might be some oversights in the handling of the "super" keyword, but this generally seems like a good architectural improvement. :^)
2020-11-28 16:02:27 +01:00
LibJS: Store and maintain an "execution generation" counter This counter is increased each time a synchronous execution sequence completes, and will allow us to emulate the abstract operations AddToKeptObjects & ClearKeptObjects efficiently.
2021-06-12 17:32:54 +03:00
u32 m_execution_generation { 0 };
LibJS: Add a way to attach custom data to a JS::VM instance This will be used by LibWeb to attach web engine specific stuff that LibJS doesn't need to know about.
2021-09-08 22:58:36 +02:00
OwnPtr<CustomData> m_custom_data;
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
OwnPtr<Bytecode::Interpreter> m_bytecode_interpreter;
LibJS+LibWeb: More bringing module loading closer to spec In particular, this patch removes three host hooks on JS::VM in favor of the new JS-side module loading stuff.
2023-12-02 22:56:47 +01:00
bool m_dynamic_imports_allowed { false };
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter Taking a big step towards a world of multiple global object, this patch adds a new JS::VM object that houses the JS::Heap. This means that the Heap moves out of Interpreter, and the same Heap can now be used by multiple Interpreters, and can also outlive them. The VM keeps a stack of Interpreter pointers. We push/pop on this stack when entering/exiting execution with a given Interpreter. This allows us to make this change without disturbing too much of the existing code. There is still a 1-to-1 relationship between Interpreter and the global object. This will change in the future. Ultimately, the goal here is to make Interpreter a transient object that only needs to exist while you execute some code. Getting there will take a lot more work though. :^) Note that in LibWeb, the global JS::VM is called main_thread_vm(), to distinguish it from future worker VM's.
2020-09-20 19:24:44 +02:00
};
LibJS: Add create_simple_execution_context<GlobalObjectType>() helper This makes it easy to set up a realm, global object and root execution context with a single call to LibJS. It will be useful to basically everyone except LibWeb.
2023-08-08 07:05:26 +02:00
template<typename GlobalObjectType, typename... Args>
[[nodiscard]] static NonnullOwnPtr<ExecutionContext> create_simple_execution_context(VM& vm, Args&&... args)
{
auto root_execution_context = MUST(Realm::initialize_host_defined_realm(
vm,
[&](Realm& realm_) -> GlobalObject* {
return vm.heap().allocate_without_realm<GlobalObjectType>(realm_, forward<Args>(args)...);
},
nullptr));
return root_execution_context;
}
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter Taking a big step towards a world of multiple global object, this patch adds a new JS::VM object that houses the JS::Heap. This means that the Heap moves out of Interpreter, and the same Heap can now be used by multiple Interpreters, and can also outlive them. The VM keeps a stack of Interpreter pointers. We push/pop on this stack when entering/exiting execution with a given Interpreter. This allows us to make this change without disturbing too much of the existing code. There is still a 1-to-1 relationship between Interpreter and the global object. This will change in the future. Ultimately, the goal here is to make Interpreter a transient object that only needs to exist while you execute some code. Getting there will take a lot more work though. :^) Note that in LibWeb, the global JS::VM is called main_thread_vm(), to distinguish it from future worker VM's.
2020-09-20 19:24:44 +02:00
}
Reference in a new issue Copy permalink