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

298 lines
12 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
/*
* Copyright (c) 2020, Andreas Kling <kling@serenityos.org>
LibJS: Implement proper Iterator records Instead of using plain objects as Iterator records, causes confusion about the object itself actually being its [[Iterator]] slot, and requires non-standard type conversion shenanigans fpr the [[NextValue]] and [[Done]] internal slots, implement a proper Iterator record struct and use it throughout. Also annotate the remaining Iterator AOs with spec comments while we're here.
2022-01-09 19:12:24 +01:00
* Copyright (c) 2020-2022, 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+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
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 <AK/FlyString.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+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: 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: Implement proper Iterator records Instead of using plain objects as Iterator records, causes confusion about the object itself actually being its [[Iterator]] slot, and requires non-standard type conversion shenanigans fpr the [[NextValue]] and [[Done]] internal slots, implement a proper Iterator record struct and use it throughout. Also annotate the remaining Iterator AOs with spec comments while we're here.
2022-01-09 19:12:24 +01:00
#include <LibJS/Runtime/Iterator.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+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: 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
};
static NonnullRefPtr<VM> create(OwnPtr<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
~VM() = default;
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
Interpreter& interpreter();
Interpreter* interpreter_if_exists();
void push_interpreter(Interpreter&);
void pop_interpreter(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: Rename InterpreterScope => InterpreterExecutionScope To make it a little clearer what this is for. (This is an RAII helper class for adding and removing an Interpreter to a VM's list of the currently active (executing code) Interpreters.)
2020-09-21 13:36:32 +02:00
class InterpreterExecutionScope {
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
public:
LibJS: Rename InterpreterScope => InterpreterExecutionScope To make it a little clearer what this is for. (This is an RAII helper class for adding and removing an Interpreter to a VM's list of the currently active (executing code) Interpreters.)
2020-09-21 13:36:32 +02:00
InterpreterExecutionScope(Interpreter&);
~InterpreterExecutionScope();
LibJS: Move the current exception from Interpreter to VM This will allow us to throw exceptions even when there is no active interpreter in the VM.
2020-09-21 15:28:09 +02:00
LibJS: Implement the NewClass opcode
2022-02-11 22:38:21 +03:30
Interpreter& interpreter() { return m_interpreter; }
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:
Interpreter& m_interpreter;
};
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
void gather_roots(HashTable<Cell*>&);
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
#define __JS_ENUMERATE(SymbolName, snake_name) \
Symbol* well_known_symbol_##snake_name() const { return m_well_known_symbol_##snake_name; }
JS_ENUMERATE_WELL_KNOWN_SYMBOLS
#undef __JS_ENUMERATE
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
Symbol* get_global_symbol(String const& description);
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: 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
HashMap<String, PrimitiveString*>& string_cache() { return m_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: 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: 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 margin in check for stack space limit test-js crashes with a segmentation fault when running on macOS on Arm. Increasing the margin in the test in did_reach_stack_space_limit() to 32 * KiB makes the tests pass. To simplify the code, this is applied independently of platform, and the previous test for use of an address sanitizer is removed.
2022-01-20 13:35:55 +01:00
// Address sanitizer (ASAN) used to check for more space but
// currently we can't detect the stack size with it enabled.
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
return m_stack_info.size_free() < 32 * KiB;
}
LibJS: Add infallible variant of VM::push_execution_context() It makes no sense to require passing a global object and doing a stack space check in some cases where running out of stack is highly unlikely, we can't recover from errors, and currently ignore the result anyway. This is most commonly in constructors and when setting things up, rather than regular function calls.
2022-03-17 22:40:17 +00:00
void push_execution_context(ExecutionContext& context)
{
m_execution_context_stack.append(&context);
}
LibJS: Convert push_execution_context() to ThrowCompletionOr
2021-11-14 12:20:49 +00:00
ThrowCompletionOr<void> push_execution_context(ExecutionContext& context, GlobalObject& global_object)
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: Throw InternalErrors instead of Errors on CallStackSizeExceeded These seem more appropriate.
2021-11-27 01:39:57 +02:00
return throw_completion<InternalError>(global_object, ErrorType::CallStackSizeExceeded);
LibJS: Convert push_execution_context() to ThrowCompletionOr
2021-11-14 12:20:49 +00:00
m_execution_context_stack.append(&context);
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: 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
void pop_execution_context()
LibJS: Add VM::on_call_stack_emptied callback Instead of having to run queued promise jobs in LibWeb in various places, this allows us to consolidate that into one function - this is very close to how the spec describes it as well ("at some future point in time, when there is no running execution context and the execution context stack is empty, the implementation must [...]"). Eventually this will also be used to log unhandled exceptions, and possibly other actions that require JS execution to have ended.
2021-04-24 18:21:02 +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
m_execution_context_stack.take_last();
if (m_execution_context_stack.is_empty() && on_call_stack_emptied)
LibJS: Add VM::on_call_stack_emptied callback Instead of having to run queued promise jobs in LibWeb in various places, this allows us to consolidate that into one function - this is very close to how the spec describes it as well ("at some future point in time, when there is no running execution context and the execution context stack is empty, the implementation must [...]"). Eventually this will also be used to log unhandled exceptions, and possibly other actions that require JS execution to have ended.
2021-04-24 18:21:02 +02:00
on_call_stack_emptied();
}
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
ExecutionContext& running_execution_context() { return *m_execution_context_stack.last(); }
ExecutionContext const& running_execution_context() const { return *m_execution_context_stack.last(); }
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: 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
auto& arguments = running_execution_context().arguments;
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 index < arguments.size() ? arguments[index] : js_undefined();
}
Value this_value(Object& global_object) 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 &global_object;
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: Convert resolve_this_binding() to ThrowCompletionOr Also add spec comments.
2021-12-30 23:00:37 +01:00
ThrowCompletionOr<Value> resolve_this_binding(GlobalObject&);
LibJS: Evaluate `this` in terms of ResolveThisBinding
2021-06-25 11:40:03 +02:00
Everywhere: Run clang-format
2022-04-01 20:58:27 +03: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: 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; }
LibJS: Convert resolve_binding() to ThrowCompletionOr The spec has a note stating that resolve binding will always return a reference whose [[ReferencedName]] field is name. However this is not correct as the underlying method GetIdentifierReference may throw on env.HasBinding(name) thus it can throw. However, there are some scenarios where it cannot throw because the reference is known to exist in that case we use MUST with a comment.
2021-12-30 14:13:20 +01:00
ThrowCompletionOr<Reference> resolve_binding(FlyString const&, Environment* = nullptr);
LibJS: Convert get_identifier_reference() to ThrowCompletionOr And while we're here add spec comments.
2021-12-30 13:19:05 +01:00
ThrowCompletionOr<Reference> get_identifier_reference(Environment*, FlyString, 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: Add VM::throw_completion helper for throwing custom Strings
2021-09-21 22:08:38 +03:00
Completion throw_completion(GlobalObject& global_object, 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+Everywhere: Remove VM::exception() and most related functions This commit removes all exception related code: Remove VM::exception(), VM::throw_exception() etc. Any leftover throw_exception calls are moved to throw_completion. The one method left is clear_exception() which is now a no-op. Most of these calls are just to clear whatever exception might have been thrown when handling a Completion. So to have a cleaner commit this will be removed in a next commit. It also removes the actual Exception and TemporaryClearException classes since these are no longer used. In any spot where the exception was actually used an attempt was made to preserve that behavior. However since it is no longer tracked by the VM we cannot access exceptions which were thrown in previous calls. There are two such cases which might have different behavior: - In Web::DOM::Document::interpreter() the on_call_stack_emptied hook used to print any uncaught exception but this is now no longer possible as the VM does not store uncaught exceptions. - In js the code used to be interruptable by throwing an exception on the VM. This is no longer possible but was already somewhat fragile before as you could happen to throw an exception just before a VERIFY.
2022-02-07 15:12:41 +01:00
return JS::throw_completion(T::create(global_object, forward<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: Add VM::throw_completion helper for throwing custom Strings
2021-09-21 22:08:38 +03:00
template<typename T, typename... Args>
Completion throw_completion(GlobalObject& global_object, ErrorType type, Args&&... args)
{
return throw_completion<T>(global_object, String::formatted(type.message(), forward<Args>(args)...));
}
LibJS: Replace uses of MarkedValueList with MarkedVector<Value> This is effectively a drop-in replacement.
2022-02-09 10:06:40 +00:00
Value construct(FunctionObject&, FunctionObject& new_target, Optional<MarkedVector<Value>> arguments);
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 console.assert()
2021-04-18 17:08:14 +02:00
String join_arguments(size_t start_index = 0) 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: 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: 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: 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: 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 enqueue_promise_job(Function<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 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: Implement [[Call]] and [[Construct]] internal slots properly This patch implements: - Spec compliant [[Call]] and [[Construct]] internal slots, as virtual FunctionObject::internal_{call,construct}(). These effectively replace the old virtual FunctionObject::{call,construct}(), but with several advantages: - Clear and consistent naming, following the object internal methods - Use of completions - internal_construct() returns an Object, and not Value! This has been a source of confusion for a long time, since in the spec there's always an Object returned but the Value return type in LibJS meant that this could not be fully trusted and something could screw you over. - Arguments are passed explicitly in form of a MarkedValueList, allowing manipulation (BoundFunction). We still put them on the execution context as a lot of code depends on it (VM::arguments()), but not from the Call() / Construct() AOs anymore, which now allows for bypassing them and invoking [[Call]] / [[Construct]] directly. Nothing but Call() / Construct() themselves do that at the moment, but future additions to ECMA262 or already existing web specs might. - Spec compliant, standalone Call() and Construct() AOs: currently the closest we have is VM::{call,construct}(), but those try to cater to all the different function object subclasses at once, resulting in a horrible mess and calling AOs with functions they should never be called with; most prominently PrepareForOrdinaryCall and OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject. As a result this also contains an implicit optimization: we no longer need to create a new function environment for NativeFunctions - which, worth mentioning, is what started this whole crusade in the first place :^)
2021-10-08 20:37:21 +01:00
ThrowCompletionOr<void> initialize_instance_elements(Object& object, ECMAScriptFunctionObject& constructor);
LibJS: Add support for public fields in classes
2021-08-28 17:11:05 +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: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
ThrowCompletionOr<void> destructuring_assignment_evaluation(NonnullRefPtr<BindingPattern> const& target, Value value, GlobalObject& global_object);
ThrowCompletionOr<void> binding_initialization(FlyString const& target, Value value, Environment* environment, GlobalObject& global_object);
ThrowCompletionOr<void> binding_initialization(NonnullRefPtr<BindingPattern> const& target, Value value, Environment* environment, GlobalObject& global_object);
ThrowCompletionOr<Value> named_evaluation_if_anonymous_function(GlobalObject& global_object, ASTNode const& expression, FlyString const& name);
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();
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.
ThrowCompletionOr<void> link_and_eval_module(Badge<Interpreter>, SourceTextModule& module);
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: 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<ThrowCompletionOr<NonnullRefPtr<Module>>(ScriptOrModule, ModuleRequest const&)> host_resolve_imported_module;
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
Function<void(ScriptOrModule, ModuleRequest, PromiseCapability)> host_import_module_dynamically;
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(ScriptOrModule, ModuleRequest const&, PromiseCapability, Promise*)> host_finish_dynamic_import;
Function<HashMap<PropertyKey, Value>(SourceTextModule const&)> host_get_import_meta_properties;
Function<void(Object*, SourceTextModule const&)> host_finalize_import_meta;
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
Function<Vector<String>()> host_get_supported_import_assertions;
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
void enable_default_host_import_module_dynamically_hook();
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: Replace uses of MarkedValueList with MarkedVector<Value> This is effectively a drop-in replacement.
2022-02-09 10:06:40 +00:00
Function<ThrowCompletionOr<Value>(GlobalObject&, JobCallback&, Value, MarkedVector<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;
Function<void(Function<ThrowCompletionOr<Value>()>, Realm*)> host_enqueue_promise_job;
Function<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: 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+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: 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
explicit VM(OwnPtr<CustomData>);
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: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
ThrowCompletionOr<void> property_binding_initialization(BindingPattern const& binding, Value value, Environment* environment, GlobalObject& global_object);
LibJS: Implement proper Iterator records Instead of using plain objects as Iterator records, causes confusion about the object itself actually being its [[Iterator]] slot, and requires non-standard type conversion shenanigans fpr the [[NextValue]] and [[Done]] internal slots, implement a proper Iterator record struct and use it throughout. Also annotate the remaining Iterator AOs with spec comments while we're here.
2022-01-09 19:12:24 +01:00
ThrowCompletionOr<void> iterator_binding_initialization(BindingPattern const& binding, Iterator& iterator_record, Environment* environment, GlobalObject& global_object);
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
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
ThrowCompletionOr<NonnullRefPtr<Module>> resolve_imported_module(ScriptOrModule referencing_script_or_module, ModuleRequest const& module_request);
LibJS: Add support for JSON modules We now have one supported assertion: 'type' if that is 'json' we attempt to parse the module as JSON.
2022-01-27 14:51:21 +01:00
ThrowCompletionOr<void> link_and_eval_module(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
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
void import_module_dynamically(ScriptOrModule referencing_script_or_module, ModuleRequest module_request, PromiseCapability promise_capability);
void finish_dynamic_import(ScriptOrModule referencing_script_or_module, ModuleRequest module_request, PromiseCapability promise_capability, Promise* inner_promise);
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: 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
HashMap<String, PrimitiveString*> m_string_cache;
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;
Vector<Interpreter*> m_interpreters;
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: 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
HashMap<String, Symbol*> m_global_symbol_map;
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
Vector<Function<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: 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
Vector<FinalizationRegistry*> m_finalization_registry_cleanup_jobs;
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* m_empty_string { nullptr };
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* m_single_ascii_character_strings[128] {};
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 {
ScriptOrModule referencing_script_or_module;
LibJS: Rename filepath to filename in module related code This is already the parameter name of Core::File::open() and VM::get_stored_module() - both of which this is passed to - as well as the member name of the Module class.
2022-06-26 20:58:32 +01:00
String filename;
LibJS: Add support for JSON modules We now have one supported assertion: 'type' if that is 'json' we attempt to parse the module as JSON.
2022-01-27 14:51:21 +01:00
String 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
NonnullRefPtr<Module> module;
bool has_once_started_linking { false };
};
LibJS: Rename filepath to filename in module related code This is already the parameter name of Core::File::open() and VM::get_stored_module() - both of which this is passed to - as well as the member name of the Module class.
2022-06-26 20:58:32 +01:00
StoredModule* get_stored_module(ScriptOrModule const& script_or_module, String const& filename, String 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 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
#define __JS_ENUMERATE(SymbolName, snake_name) \
Symbol* m_well_known_symbol_##snake_name { nullptr };
JS_ENUMERATE_WELL_KNOWN_SYMBOLS
#undef __JS_ENUMERATE
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+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: Always inline Cell::vm() and Cell::heap()
2021-03-21 17:20:07 +01:00
ALWAYS_INLINE Heap& Cell::heap() const
{
return HeapBlock::from_cell(this)->heap();
}
ALWAYS_INLINE VM& Cell::vm() const
{
return heap().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
}
Reference in a new issue Copy permalink