1
Fork 0
mirror of https://github.com/RGBCube/serenity synced 2025-05-14 10:05:00 +00:00
Commit graph

15 commits

Author SHA1 Message Date
Ali Mohammad Pur
5e1499d104 Everywhere: Rename {Deprecated => Byte}String
This commit un-deprecates DeprecatedString, and repurposes it as a byte
string.
As the null state has already been removed, there are no other
particularly hairy blockers in repurposing this type as a byte string
(what it _really_ is).

This commit is auto-generated:
  $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \
    Meta Ports Ladybird Tests Kernel)
  $ perl -pie 's/\bDeprecatedString\b/ByteString/g;
    s/deprecated_string/byte_string/g' $xs
  $ clang-format --style=file -i \
    $(git diff --name-only | grep \.cpp\|\.h)
  $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-17 18:25:10 +03:30
Andreas Kling
3c74dc9f4d LibJS: Segregate GC-allocated objects by type
This patch adds two macros to declare per-type allocators:

- JS_DECLARE_ALLOCATOR(TypeName)
- JS_DEFINE_ALLOCATOR(TypeName)

When used, they add a type-specific CellAllocator that the Heap will
delegate allocation requests to.

The result of this is that GC objects of the same type always end up
within the same HeapBlock, drastically reducing the ability to perform
type confusion attacks.

It also improves HeapBlock utilization, since each block now has cells
sized exactly to the type used within that block. (Previously we only
had a handful of block sizes available, and most GC allocations ended
up with a large amount of slack in their tails.)

There is a small performance hit from this, but I'm sure we can make
up for it elsewhere.

Note that the old size-based allocators still exist, and we fall back
to them for any type that doesn't have its own CellAllocator.
2023-11-19 12:10:31 +01:00
Andreas Kling
72c9f56c66 LibJS: Make Heap::allocate<T>() infallible
Stop worrying about tiny OOMs. Work towards #20449.

While going through these, I also changed the function signature in many
places where returning ThrowCompletionOr<T> is no longer necessary.
2023-08-13 15:38:42 +02:00
Andreas Kling
18c54d8d40 LibJS: Make Cell::initialize() return void
Stop worrying about tiny OOMs.

Work towards #20405
2023-08-08 07:39:11 +02:00
Daniel Bertalan
e64a8751d1 LibJS: Do not use the $ special character in file names
The dollar sign is a special character in POSIX shells and in the Ninja
build file format. If the file name contains a `$`, something goes wrong
in the escaping/unescaping of this symbol, and CMake/GCC/Clang generate
invalid dependency files where not all instances of `$` are escaped
properly. Because of this, Ninja fails to rebuild `$262Object.cpp` if
the headers included by it have changed.

Stale `$262Object.cpp.o` files have been the cause of mysterious crashes
multiple times which only go away after doing a clean build. Let's
prevent these from happening again by removing the `$` from the
filename.
2023-07-15 11:09:22 -04:00
Timothy Flynn
b75b7f0c0d LibJS+Everywhere: Propagate Cell::initialize errors from Heap::allocate
Callers that are already in a fallible context will now TRY to allocate
cells. Callers in infallible contexts get a FIXME.
2023-01-29 00:02:45 +00:00
Timothy Flynn
2692db8699 LibJS+Everywhere: Allow Cell::initialize overrides to throw OOM errors
Note that as of this commit, there aren't any such throwers, and the
call site in Heap::allocate will drop exceptions on the floor. This
commit only serves to change the declaration of the overrides, make sure
they return an empty value, and to propagate OOM errors frm their base
initialize invocations.
2023-01-29 00:02:45 +00:00
Timothy Flynn
afeb7273cc LibJS+Everywhere: Rename Value::to_string to to_deprecated_string 2023-01-15 01:00:20 +00:00
Linus Groh
cfa5885855 LibJS: Turn initialize_global_object() into a regular initialize()
There's nothing special about global object initialization anymore, this
can just work the same way as for any other object now.
2022-08-28 16:36:56 +01:00
Linus Groh
e3895e6c80 LibJS: Pass Realm to define_native_{accessor,function}()
This is needed so that the allocated NativeFunction receives the correct
realm, usually forwarded from the Object's initialize() function, rather
than using the current realm.
2022-08-23 13:58:30 +01:00
Linus Groh
7c468b5a77 LibJS: Pass Realm to GlobalObject::initialize_global_object()
Global object initialization is tightly coupled to realm creation, so
simply pass it to the function instead of relying on the non-standard
'associated realm' concept, which I'd like to remove later.

This works essentially the same way as regular Object::initialize() now.

Additionally this allows us to forward the realm to GlobalObject's
add_constructor() / initialize_constructor() helpers, so they set the
correct realm on the allocated constructor function object.
2022-08-23 13:58:30 +01:00
Linus Groh
a022e548b8 LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19]
This is where the fun begins. :^)
2022-08-23 13:58:30 +01:00
Linus Groh
e992a9f469 LibJS+LibWeb: Replace GlobalObject with Realm in Heap::allocate<T>()
This is a continuation of the previous three commits.

Now that create() receives the allocating realm, we can simply forward
that to allocate(), which accounts for the majority of these changes.
Additionally, we can get rid of the realm_from_global_object() in one
place, with one more remaining in VM::throw_completion().
2022-08-23 13:58:30 +01:00
Linus Groh
ecd163bdf1 LibJS+LibWeb: Replace GlobalObject with Realm in object constructors
No functional changes - we can still very easily get to the global
object via `Realm::global_object()`. This is in preparation of moving
the intrinsics to the realm and no longer having to pass a global
object when allocating any object.
In a few (now, and many more in subsequent commits) places we get a
realm using `GlobalObject::associated_realm()`, this is intended to be
temporary. For example, create() functions will later receive the same
treatment and are passed a realm instead of a global object.
2022-08-23 13:58:30 +01:00
Linus Groh
1e01a85cdf LibJS: Import C++ sources from libjs-test262 :^)
This commit upstreams most of the C++ bits of the LibJS test262 runner
at https://github.com/linusg/libjs-test262/, specifically everything but
the main.cpp file serving as the actual executable.
Since all of these are just regular JS objects, I opted to put them in
LibJS itself, in a new Contrib/ directory like many other projects have
one. Other code that can end up there in the future is the runtime for
esvu, which might even share some functionality with test262's $262
object.

The code has been copied verbatim, and only a small number of changes
have been made:

- Putting everything into the JS::Test262 namespace
- Removing now redundant JS namespace prefixes
- Updating includes to use absolute <LibJS/...> paths
- Updating the SPDX-License-Identifier comments from MIT to BSD-2-Clause

I gained permission to change the license and upstream these changes
from all the major contributors to this code: Ali, Andrew, David, Idan.

The removal of the code from the source repository is here:
https://github.com/linusg/libjs-test262/pull/54

This is only the first step, the goal is to eventually upstream the
actual libjs-test262-runner executable and supporting Python scripts
into SerenityOS as well.
2022-03-29 21:01:08 +01:00