Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-03 23:00:58 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibJS/Runtime/Intrinsics.h

219 lines
9.7 KiB
C
Raw Normal View History

LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
/*
LibJS: Make namespace object initialization lazy as well
2023-01-09 23:59:08 +00:00
* Copyright (c) 2022-2023, Linus Groh <linusg@serenityos.org>
LibJS: Cache the Intl.Collator in String.prototype.localeCompare() In the very common case that no special constructor options are provided for the Intl.Collator when calling localeCompare() on a string, we can cache and reuse a default-constructed Intl.Collator, saving lots of time and space. This shaves a fair bit of load time off of https://wpt.fyi/ where they use Array.prototype.sort() and localeCompare() to sort a big JSON thing. Time spent in sort(): - Before: 1656 ms - After: 135 ms
2025-01-23 18:20:29 +01:00
* Copyright (c) 2020-2025, Andreas Kling <andreas@ladybird.org>
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
LibJS: Add missing include to Intrinsics.h This was preventing clangd in my environment from processing the Intrinsics class.
2025-02-03 21:32:41 -05:00
#include <LibGC/CellAllocator.h>
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
#include <LibJS/Forward.h>
#include <LibJS/Heap/Cell.h>
namespace JS {
class Intrinsics final : public Cell {
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC_CELL(Intrinsics, Cell);
GC_DECLARE_ALLOCATOR(Intrinsics);
LibJS: Add JS_CELL macro and use it in all JS::Cell subclasses This is similar to what we already had with JS_OBJECT (and also JS_ENVIRONMENT) but sits at the top of the Cell inheritance hierarchy.
2022-08-28 22:11:20 +02:00
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
public:
LibJS: Remove OOM handling from JS intrinsics initialization
2025-02-03 21:33:19 -05:00
static GC::Ref<Intrinsics> create(Realm&);
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ref<Shape> empty_object_shape() { return *m_empty_object_shape; }
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ref<Shape> new_object_shape() { return *m_new_object_shape; }
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
[[nodiscard]] GC::Ref<Shape> iterator_result_object_shape() { return *m_iterator_result_object_shape; }
LibJS: Use a premade shape when creating iterator result objects Instead of going through the steps of creating an empty new object, and adding two properties ("value" and "done") to it, we can pre-bake a shape object and cache the property offsets. This makes creating iterator result objects in the runtime much faster. 47% speedup on this microbenchmark: function go(a) { for (const p of a) { } } const a = []; a.length = 1_000_000; go(a);
2023-12-07 22:30:53 +01:00
[[nodiscard]] u32 iterator_result_object_value_offset() { return m_iterator_result_object_value_offset; }
[[nodiscard]] u32 iterator_result_object_done_offset() { return m_iterator_result_object_done_offset; }
LibJS: Use a premade shape for normal function object prototypes This avoids one shape allocation per function instantiation.
2025-03-25 19:16:11 +00:00
[[nodiscard]] GC::Ref<Shape> normal_function_prototype_shape() { return *m_normal_function_prototype_shape; }
[[nodiscard]] u32 normal_function_prototype_constructor_offset() const { return m_normal_function_prototype_constructor_offset; }
LibJS: Use a premade shape for normal function objects This avoids going through all the shape transitions when setting up the most common form of ESFO. This is extremely hot on Uber Eats, and this provides some relief.
2025-03-25 20:08:38 +00:00
[[nodiscard]] GC::Ref<Shape> normal_function_shape() { return *m_normal_function_shape; }
[[nodiscard]] u32 normal_function_length_offset() const { return m_normal_function_length_offset; }
[[nodiscard]] u32 normal_function_name_offset() const { return m_normal_function_name_offset; }
[[nodiscard]] u32 normal_function_prototype_offset() const { return m_normal_function_prototype_offset; }
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
// Not included in JS_ENUMERATE_NATIVE_OBJECTS due to missing distinct prototype
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ref<ProxyConstructor> proxy_constructor() { return *m_proxy_constructor; }
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
// Not included in JS_ENUMERATE_NATIVE_OBJECTS due to missing distinct constructor
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ref<Object> async_from_sync_iterator_prototype() { return *m_async_from_sync_iterator_prototype; }
GC::Ref<Object> async_generator_prototype() { return *m_async_generator_prototype; }
GC::Ref<Object> generator_prototype() { return *m_generator_prototype; }
GC::Ref<Object> wrap_for_valid_iterator_prototype() { return *m_wrap_for_valid_iterator_prototype; }
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
// Alias for the AsyncGenerator Prototype Object used by the spec (%AsyncGeneratorFunction.prototype.prototype%)
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ref<Object> async_generator_function_prototype_prototype() { return *m_async_generator_prototype; }
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
// Alias for the Generator Prototype Object used by the spec (%GeneratorFunction.prototype.prototype%)
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ref<Object> generator_function_prototype_prototype() { return *m_generator_prototype; }
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
// Not included in JS_ENUMERATE_INTL_OBJECTS due to missing distinct constructor
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ref<Object> intl_segments_prototype() { return *m_intl_segments_prototype; }
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
LibJS: Move construction of GlobalObject native functions to Intrinsics This will later allow global objects not inheriting from the regular JS::GlobalObject to pull in these functions without having to implement them from scratch. The primary use case here is, again, a wrapper-less HTML::Window in LibWeb :^) Allocating these upfront now allows us to get rid of two hacks: - The GlobalObject assigning Intrinsics private members after finishing its initialization - The GlobalObject defining the parseInt and parseFloat properties of the NumberConstructor object, as they are supposed to be identical with the global functions of the same name
2022-08-28 17:09:31 +01:00
// Global object functions
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ref<FunctionObject> eval_function() const { return *m_eval_function; }
GC::Ref<FunctionObject> is_finite_function() const { return *m_is_finite_function; }
GC::Ref<FunctionObject> is_nan_function() const { return *m_is_nan_function; }
GC::Ref<FunctionObject> parse_float_function() const { return *m_parse_float_function; }
GC::Ref<FunctionObject> parse_int_function() const { return *m_parse_int_function; }
GC::Ref<FunctionObject> decode_uri_function() const { return *m_decode_uri_function; }
GC::Ref<FunctionObject> decode_uri_component_function() const { return *m_decode_uri_component_function; }
GC::Ref<FunctionObject> encode_uri_function() const { return *m_encode_uri_function; }
GC::Ref<FunctionObject> encode_uri_component_function() const { return *m_encode_uri_component_function; }
GC::Ref<FunctionObject> escape_function() const { return *m_escape_function; }
GC::Ref<FunctionObject> unescape_function() const { return *m_unescape_function; }
LibJS: Move construction of GlobalObject native functions to Intrinsics This will later allow global objects not inheriting from the regular JS::GlobalObject to pull in these functions without having to implement them from scratch. The primary use case here is, again, a wrapper-less HTML::Window in LibWeb :^) Allocating these upfront now allows us to get rid of two hacks: - The GlobalObject assigning Intrinsics private members after finishing its initialization - The GlobalObject defining the parseInt and parseFloat properties of the NumberConstructor object, as they are supposed to be identical with the global functions of the same name
2022-08-28 17:09:31 +01:00
// Namespace/constructor object functions
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ref<FunctionObject> array_prototype_values_function() const { return *m_array_prototype_values_function; }
GC::Ref<FunctionObject> date_constructor_now_function() const { return *m_date_constructor_now_function; }
GC::Ref<FunctionObject> json_parse_function() const { return *m_json_parse_function; }
GC::Ref<FunctionObject> json_stringify_function() const { return *m_json_stringify_function; }
GC::Ref<FunctionObject> object_prototype_to_string_function() const { return *m_object_prototype_to_string_function; }
GC::Ref<FunctionObject> throw_type_error_function() const { return *m_throw_type_error_function; }
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
#define __JS_ENUMERATE(ClassName, snake_name, PrototypeName, ConstructorName, ArrayType) \
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ref<ConstructorName> snake_name##_constructor(); \
GC::Ref<Object> snake_name##_prototype();
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
JS_ENUMERATE_BUILTIN_TYPES
#undef __JS_ENUMERATE
#define __JS_ENUMERATE(ClassName, snake_name, PrototypeName, ConstructorName) \
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ref<Intl::ConstructorName> intl_##snake_name##_constructor(); \
GC::Ref<Object> intl_##snake_name##_prototype();
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
JS_ENUMERATE_INTL_OBJECTS
#undef __JS_ENUMERATE
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
#define __JS_ENUMERATE(ClassName, snake_name, PrototypeName, ConstructorName) \
GC::Ref<Temporal::ConstructorName> temporal_##snake_name##_constructor(); \
GC::Ref<Object> temporal_##snake_name##_prototype();
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
JS_ENUMERATE_TEMPORAL_OBJECTS
#undef __JS_ENUMERATE
#define __JS_ENUMERATE(ClassName, snake_name) \
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ref<ClassName> snake_name##_object();
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
JS_ENUMERATE_BUILTIN_NAMESPACE_OBJECTS
#undef __JS_ENUMERATE
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
#define __JS_ENUMERATE(ClassName, snake_name) \
GC::Ref<Object> snake_name##_prototype() \
{ \
return *m_##snake_name##_prototype; \
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
}
JS_ENUMERATE_ITERATOR_PROTOTYPES
#undef __JS_ENUMERATE
LibJS: Cache the Intl.Collator in String.prototype.localeCompare() In the very common case that no special constructor options are provided for the Intl.Collator when calling localeCompare() on a string, we can cache and reuse a default-constructed Intl.Collator, saving lots of time and space. This shaves a fair bit of load time off of https://wpt.fyi/ where they use Array.prototype.sort() and localeCompare() to sort a big JSON thing. Time spent in sort(): - Before: 1656 ms - After: 135 ms
2025-01-23 18:20:29 +01:00
[[nodiscard]] GC::Ref<Intl::Collator> default_collator();
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
private:
LibJS: Lazily initialize most Realm instrinsic contructors/prototypes This changes Intrinsics to not initialize most of its constructors and prototype right away. We still initialize a few that are needed before some others are created, though we may eventually be able to "link" dependencies at compile time to avoid this.
2022-11-23 12:55:31 -05:00
Intrinsics(Realm& realm)
: m_realm(realm)
{
}
LibJS: Hide all the constructors! Now that the GC allocator is able to invoke Cell subclass constructors directly via friendship, we no longer need to keep them public. :^)
2022-08-28 23:51:28 +02:00
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
virtual void visit_edges(Visitor&) override;
LibJS: Remove OOM handling from JS intrinsics initialization
2025-02-03 21:33:19 -05:00
void initialize_intrinsics(Realm&);
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
LibJS: Lazily initialize most Realm instrinsic contructors/prototypes This changes Intrinsics to not initialize most of its constructors and prototype right away. We still initialize a few that are needed before some others are created, though we may eventually be able to "link" dependencies at compile time to avoid this.
2022-11-23 12:55:31 -05:00
#define __JS_ENUMERATE(ClassName, snake_name, PrototypeName, ConstructorName, ArrayType) \
void initialize_##snake_name();
JS_ENUMERATE_BUILTIN_TYPES
#undef __JS_ENUMERATE
#define __JS_ENUMERATE(ClassName, snake_name, PrototypeName, ConstructorName) \
void initialize_intl_##snake_name();
JS_ENUMERATE_INTL_OBJECTS
#undef __JS_ENUMERATE
#define __JS_ENUMERATE(ClassName, snake_name, PrototypeName, ConstructorName) \
void initialize_temporal_##snake_name();
JS_ENUMERATE_TEMPORAL_OBJECTS
#undef __JS_ENUMERATE
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ref<Realm> m_realm;
LibJS: Lazily initialize most Realm instrinsic contructors/prototypes This changes Intrinsics to not initialize most of its constructors and prototype right away. We still initialize a few that are needed before some others are created, though we may eventually be able to "link" dependencies at compile time to avoid this.
2022-11-23 12:55:31 -05:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<Shape> m_empty_object_shape;
GC::Ptr<Shape> m_new_object_shape;
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<Shape> m_iterator_result_object_shape;
LibJS: Use a premade shape when creating iterator result objects Instead of going through the steps of creating an empty new object, and adding two properties ("value" and "done") to it, we can pre-bake a shape object and cache the property offsets. This makes creating iterator result objects in the runtime much faster. 47% speedup on this microbenchmark: function go(a) { for (const p of a) { } } const a = []; a.length = 1_000_000; go(a);
2023-12-07 22:30:53 +01:00
u32 m_iterator_result_object_value_offset { 0 };
u32 m_iterator_result_object_done_offset { 0 };
LibJS: Use a premade shape for normal function object prototypes This avoids one shape allocation per function instantiation.
2025-03-25 19:16:11 +00:00
GC::Ptr<Shape> m_normal_function_prototype_shape;
u32 m_normal_function_prototype_constructor_offset { 0 };
LibJS: Use a premade shape for normal function objects This avoids going through all the shape transitions when setting up the most common form of ESFO. This is extremely hot on Uber Eats, and this provides some relief.
2025-03-25 20:08:38 +00:00
GC::Ptr<Shape> m_normal_function_shape;
u32 m_normal_function_length_offset { 0 };
u32 m_normal_function_name_offset { 0 };
u32 m_normal_function_prototype_offset { 0 };
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
// Not included in JS_ENUMERATE_NATIVE_OBJECTS due to missing distinct prototype
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<ProxyConstructor> m_proxy_constructor;
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
// Not included in JS_ENUMERATE_NATIVE_OBJECTS due to missing distinct constructor
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<Object> m_async_from_sync_iterator_prototype;
GC::Ptr<Object> m_async_generator_prototype;
GC::Ptr<Object> m_generator_prototype;
GC::Ptr<Object> m_wrap_for_valid_iterator_prototype;
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
// Not included in JS_ENUMERATE_INTL_OBJECTS due to missing distinct constructor
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<Object> m_intl_segments_prototype;
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
LibJS: Move construction of GlobalObject native functions to Intrinsics This will later allow global objects not inheriting from the regular JS::GlobalObject to pull in these functions without having to implement them from scratch. The primary use case here is, again, a wrapper-less HTML::Window in LibWeb :^) Allocating these upfront now allows us to get rid of two hacks: - The GlobalObject assigning Intrinsics private members after finishing its initialization - The GlobalObject defining the parseInt and parseFloat properties of the NumberConstructor object, as they are supposed to be identical with the global functions of the same name
2022-08-28 17:09:31 +01:00
// Global object functions
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<FunctionObject> m_eval_function;
GC::Ptr<FunctionObject> m_is_finite_function;
GC::Ptr<FunctionObject> m_is_nan_function;
GC::Ptr<FunctionObject> m_parse_float_function;
GC::Ptr<FunctionObject> m_parse_int_function;
GC::Ptr<FunctionObject> m_decode_uri_function;
GC::Ptr<FunctionObject> m_decode_uri_component_function;
GC::Ptr<FunctionObject> m_encode_uri_function;
GC::Ptr<FunctionObject> m_encode_uri_component_function;
GC::Ptr<FunctionObject> m_escape_function;
GC::Ptr<FunctionObject> m_unescape_function;
LibJS: Move construction of GlobalObject native functions to Intrinsics This will later allow global objects not inheriting from the regular JS::GlobalObject to pull in these functions without having to implement them from scratch. The primary use case here is, again, a wrapper-less HTML::Window in LibWeb :^) Allocating these upfront now allows us to get rid of two hacks: - The GlobalObject assigning Intrinsics private members after finishing its initialization - The GlobalObject defining the parseInt and parseFloat properties of the NumberConstructor object, as they are supposed to be identical with the global functions of the same name
2022-08-28 17:09:31 +01:00
// Namespace/constructor object functions
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<FunctionObject> m_array_prototype_values_function;
GC::Ptr<FunctionObject> m_date_constructor_now_function;
GC::Ptr<FunctionObject> m_json_parse_function;
GC::Ptr<FunctionObject> m_json_stringify_function;
GC::Ptr<FunctionObject> m_object_prototype_to_string_function;
GC::Ptr<FunctionObject> m_throw_type_error_function;
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
#define __JS_ENUMERATE(ClassName, snake_name, PrototypeName, ConstructorName, ArrayType) \
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<ConstructorName> m_##snake_name##_constructor; \
GC::Ptr<Object> m_##snake_name##_prototype;
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
JS_ENUMERATE_BUILTIN_TYPES
#undef __JS_ENUMERATE
#define __JS_ENUMERATE(ClassName, snake_name, PrototypeName, ConstructorName) \
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<Intl::ConstructorName> m_intl_##snake_name##_constructor; \
GC::Ptr<Object> m_intl_##snake_name##_prototype;
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
JS_ENUMERATE_INTL_OBJECTS
#undef __JS_ENUMERATE
LibJS+LibWeb: Wrap raw JS::Cell*/& fields in GCPtr/NonnullGCPtr
2023-02-26 16:09:02 -07:00
#define __JS_ENUMERATE(ClassName, snake_name, PrototypeName, ConstructorName) \
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<Temporal::ConstructorName> m_temporal_##snake_name##_constructor; \
GC::Ptr<Object> m_temporal_##snake_name##_prototype;
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
JS_ENUMERATE_TEMPORAL_OBJECTS
#undef __JS_ENUMERATE
#define __JS_ENUMERATE(ClassName, snake_name) \
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<ClassName> m_##snake_name##_object;
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
JS_ENUMERATE_BUILTIN_NAMESPACE_OBJECTS
#undef __JS_ENUMERATE
#define __JS_ENUMERATE(ClassName, snake_name) \
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<Object> m_##snake_name##_prototype;
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
JS_ENUMERATE_ITERATOR_PROTOTYPES
#undef __JS_ENUMERATE
LibJS: Cache the Intl.Collator in String.prototype.localeCompare() In the very common case that no special constructor options are provided for the Intl.Collator when calling localeCompare() on a string, we can cache and reuse a default-constructed Intl.Collator, saving lots of time and space. This shaves a fair bit of load time off of https://wpt.fyi/ where they use Array.prototype.sort() and localeCompare() to sort a big JSON thing. Time spent in sort(): - Before: 1656 ms - After: 135 ms
2025-01-23 18:20:29 +01:00
GC::Ptr<Intl::Collator> m_default_collator;
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
};
void add_restricted_function_properties(FunctionObject&, Realm&);
}
Reference in a new issue Copy permalink