This replaces ctype.h with CharacterType.h everywhere I could find
issues with narrowing conversions. While using it will probably make
sense almost everywhere in the future, the most critical places should
have been addressed.
In hindsight declaring these prematurely wasn't the greatest idea - that
just makes any script checking for their existence believe they'll work,
and what follows next is a crash of the js or WebContent process. If we
omit the declarations, a polyfill can be provided instead.
This also affects the test262, which tests these - instead of reporting
a bunch of assertion crash errors, we should simply report test failure
for 'not a function', which in turn makes it easier to spot any actual
bugs causing crashes.
There's no reason at all for this to be a string or to accept arbitrary
values - just because it's displayed as strings in the spec doesn't mean
we have to do the same :^)
Checking for this (and get()'ing it) is always invalid, so let's just
disallow it.
This also finds two bugs where the code is checking for types that can
never actually be in the variant (which was actually a refactor
artifact).
Mark the entirety of a heap block's storage poisoned at construction.
Unpoison all of a Cell's memory before allocating it, and re-poison as
much as possible on deallocation. Unfortunately, the entirety of the
FreelistEntry must be kept unpoisoned in order for reallocation to work
correctly.
Decreasing the size of FreelistEntry or adding a larger redzone to Cells
would make the instrumentation even better.
Use this to avoid creating a 16 byte cell allocator on x86_64, where the
size of FreelistEntry is 24 bytes. Every JS::Cell must be at least the
size of the FreelistEntry or things start crashing, so the 16 byte
allocator was wasted on that platform.
This is the coarsest grained ASAN instrumentation possible for the LibJS
heap. Future instrumentation could add red-zones to heap block
allocations, and poison the entire heap block and only un-poison used
cells at the CellAllocator level.
The previous VERIFY() call checked that aligned_alloc() didn't return
MAP_FAILED. When out of memory aligned_alloc() returns a null pointer
so let's check for that instead.
This patch adds a BlockAllocator to the GC heap where we now cache up to
64 HeapBlock-sized mmap's that get recycled when allocating HeapBlocks.
This improves test-js runtime performance by ~35%, pretty cool! :^)
Instead of being its own separate unrelated class.
This automatically makes typed array properties available to it,
as well as making it available to the runtime.
So far we only have two states: Live and Dead. In the future, we can
add additional states to support incremental sweeping and/or multi-
stage cell destruction.
We had two functions for doing mostly the same thing. Combine both
of them into String::find() and use that everywhere.
Also add some tests to cover basic behavior.
By doing the offset calculation in {get,put}_by_index() we would
delegate these operations to Object for any index >= (array length -
byte offset). By doing the offset calculation in data() instead, we can
just use the unaltered property index for indexing the returned Span.
In other words: data()[0] now returns the same value as indexing the
TypedArray at index 0 in JS.
This also fixes a bug in the js REPL which would not consider the byte
offset and subsequently access the underlying ArrayBuffer data with a
wrong index.
Problem:
- `static` variables consume memory and sometimes are less
optimizable.
- `static const` variables can be `constexpr`, usually.
- `static` function-local variables require an initialization check
every time the function is run.
Solution:
- If a global `static` variable is only used in a single function then
move it into the function and make it non-`static` and `constexpr`.
- Make all global `static` variables `constexpr` instead of `const`.
- Change function-local `static const[expr]` variables to be just
`constexpr`.
We already do this for the SimpleIndexedPropertyStorage, so for indexed
properties with GenericIndexedPropertyStorage this would previously
crash. Since overwriting the array-like size with a larger value won't
magically insert values at previously unset indices, we need to handle
such an out of bounds access gracefully and just return an empty value.
Fixes#7043.
