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/Libraries/LibJS/Runtime/Intrinsics.h

258 lines
12 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: Enable EXPLICIT_SYMBOL_EXPORT and annotate minimum symbol set
2025-07-19 13:49:30 -07:00
#include <LibJS/Export.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 {
LibJS: Enable EXPLICIT_SYMBOL_EXPORT and annotate minimum symbol set
2025-07-19 13:49:30 -07:00
class JS_API 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: Use a premade shape for NativeFunction with length and name ~2% of the Speedometer 2.1 profile was just repeatedly performing the shape transitions to add these two properties. We can avoid all that work by caching a premade shape.
2025-04-08 22:23:28 +02:00
[[nodiscard]] GC::Ref<Shape> native_function_shape() { return *m_native_function_shape; }
[[nodiscard]] u32 native_function_length_offset() const { return m_native_function_length_offset; }
[[nodiscard]] u32 native_function_name_offset() const { return m_native_function_name_offset; }
LibJS: Use premade shape when creating unmapped arguments objects Takes Speedometer2.1/EmberJS-Debug-TodoMVC from ~4500ms to ~4000ms on my M3 MacBook Pro.
2025-04-14 23:41:31 +02:00
[[nodiscard]] GC::Ref<Shape> unmapped_arguments_object_shape() { return *m_unmapped_arguments_object_shape; }
[[nodiscard]] u32 unmapped_arguments_object_length_offset() const { return m_unmapped_arguments_object_length_offset; }
[[nodiscard]] u32 unmapped_arguments_object_well_known_symbol_iterator_offset() const { return m_unmapped_arguments_object_well_known_symbol_iterator_offset; }
[[nodiscard]] u32 unmapped_arguments_object_callee_offset() const { return m_unmapped_arguments_object_callee_offset; }
LibJS: Use premade shape when creating mapped arguments objects Knocks out a 0.4% profile item on Speedometer 3.
2025-04-18 18:11:10 +02:00
[[nodiscard]] GC::Ref<Shape> mapped_arguments_object_shape() { return *m_mapped_arguments_object_shape; }
[[nodiscard]] u32 mapped_arguments_object_length_offset() const { return m_mapped_arguments_object_length_offset; }
[[nodiscard]] u32 mapped_arguments_object_well_known_symbol_iterator_offset() const { return m_mapped_arguments_object_well_known_symbol_iterator_offset; }
[[nodiscard]] u32 mapped_arguments_object_callee_offset() const { return m_mapped_arguments_object_callee_offset; }
LibJS: Skip prototype chain lookup in `internal_set()` for arrays ...when Array.prototype and Object.prototype are intact. If `internal_set()` is called on an array exotic object with a numeric PropertyKey, and: - the prototype chain has not been modified (i.e., there are no getters or setters for indexed properties), and - the array is not the target of a Proxy object, then we can directly store the value in the receiver's indexed properties, without checking whether it already exists somewhere in the prototype chain. 1.7x improvement on the following program: ```js function f() { let a = []; let i = 0; while (i < 10_000_000) { a.push(i); i++; } } f(); ```
2025-05-22 19:46:08 +03:00
[[nodiscard]] GC::Ref<Shape> default_array_prototype_shape() const { return *m_default_array_prototype_shape; }
[[nodiscard]] GC::Ref<Shape> default_object_prototype_shape() const { return *m_default_object_prototype_shape; }
LibJS: Use premade shape when creating unmapped arguments objects Takes Speedometer2.1/EmberJS-Debug-TodoMVC from ~4500ms to ~4000ms on my M3 MacBook Pro.
2025-04-14 23:41:31 +02:00
[[nodiscard]] GC::Ref<Accessor> throw_type_error_accessor() { return *m_throw_type_error_accessor; }
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: Use a premade shape for NativeFunction with length and name ~2% of the Speedometer 2.1 profile was just repeatedly performing the shape transitions to add these two properties. We can avoid all that work by caching a premade shape.
2025-04-08 22:23:28 +02:00
GC::Ptr<Shape> m_native_function_shape;
u32 m_native_function_length_offset { 0 };
u32 m_native_function_name_offset { 0 };
LibJS: Use premade shape when creating unmapped arguments objects Takes Speedometer2.1/EmberJS-Debug-TodoMVC from ~4500ms to ~4000ms on my M3 MacBook Pro.
2025-04-14 23:41:31 +02:00
GC::Ptr<Shape> m_unmapped_arguments_object_shape;
u32 m_unmapped_arguments_object_length_offset { 0 };
u32 m_unmapped_arguments_object_well_known_symbol_iterator_offset { 0 };
u32 m_unmapped_arguments_object_callee_offset { 0 };
LibJS: Use premade shape when creating mapped arguments objects Knocks out a 0.4% profile item on Speedometer 3.
2025-04-18 18:11:10 +02:00
GC::Ptr<Shape> m_mapped_arguments_object_shape;
u32 m_mapped_arguments_object_length_offset { 0 };
u32 m_mapped_arguments_object_well_known_symbol_iterator_offset { 0 };
u32 m_mapped_arguments_object_callee_offset { 0 };
LibJS: Skip prototype chain lookup in `internal_set()` for arrays ...when Array.prototype and Object.prototype are intact. If `internal_set()` is called on an array exotic object with a numeric PropertyKey, and: - the prototype chain has not been modified (i.e., there are no getters or setters for indexed properties), and - the array is not the target of a Proxy object, then we can directly store the value in the receiver's indexed properties, without checking whether it already exists somewhere in the prototype chain. 1.7x improvement on the following program: ```js function f() { let a = []; let i = 0; while (i < 10_000_000) { a.push(i); i++; } } f(); ```
2025-05-22 19:46:08 +03:00
GC::Ptr<Shape> m_default_array_prototype_shape;
GC::Ptr<Shape> m_default_object_prototype_shape;
LibJS: Use premade shape when creating unmapped arguments objects Takes Speedometer2.1/EmberJS-Debug-TodoMVC from ~4500ms to ~4000ms on my M3 MacBook Pro.
2025-04-14 23:41:31 +02:00
GC::Ptr<Accessor> m_throw_type_error_accessor;
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
};
LibJS: Revert Enable EXPLICIT_SYMBOL_EXPORT This reverts commit c14173f651f5a50fdb86beb4b79487454a00f3f6. We should only annotate the minimum number of symbols that external consumers actually use, so I am starting from scratch to do that
2025-07-19 10:41:08 -07:00
void add_restricted_function_properties(FunctionObject&, 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
}
Reference in a new issue Copy permalink