There is no need to do a full linear search from start to end when
we can just remember the position and continue where we left off.
(cherry picked from commit f4e24762846cfb7a98054f700319d940173086bb)
This avoids having to do O(n) contains() in the various flag accessors.
Yields a ~20% speed-up on the following microbenchmark:
const re = /foo/dgimsvy;
for (let i = 0; i < 1_000_000; ++i)
re.flags;
(cherry picked from commit 257ebea3645ab709be4a984100cc6478b289d0e6)
`find_binding_and_index` was doing a linear search, and while most
environments are small, websites using JavaScript bundlers can have
functions with very large environments, like youtube.com, which has
environments with over 13K bindings, causing environment lookups to
take a noticeable amount of time, showing up high while profiling.
Adding a HashMap significantly increases performance on such websites.
(cherry picked from commit 78ecde9923e954e8ae9bb8d7a8ceefc08a8130ae)
This proposal has reached stage 4 and was merged into the ECMA-262 spec.
See: https://github.com/tc39/ecma262/commit/961f269
(cherry picked from commit 84ad36de0692b8890a2aa7ab66ed4d679cf630c8;
amended to replace one ASSERT() with VERIFY())
This proposal has reached stage 4 and was merged into the ECMA-262 spec.
See: https://github.com/tc39/ecma262/commit/d72630f
(cherry picked from commit 3aca12d2fadca1628a4dd2f800050b4e54194d65)
This implements the proposed update to the ShadowRealm proposal for
integrating the ShadowRealm specification into the web platform.
(cherry picked from commit d1fc76bffdafe5a057c0da5855d9d643608bd726)
This allows us to align our implementation in the same order as the
specification.
No functional change with the current implementation of this AO.
However, this change is required in order to correctly implement a
proposed update of the shadow realm proposal for integration with
the HTML spec host bindings in order to give the ShadowRealm
object the correct 'intrinsic' realm.
This is due to that proposed change adding a step which manipulates the
currently executing Javascript execution context, making the ordering
important.
(cherry picked from commit 0ec8af5b70702e9ee2edc7269c103fa49e6987c1)
We were storing these in Handle (strong GC roots) hanging off of
ECMAScriptFunctionObject which effectively turned into world leaks.
(cherry picked from commit 5aa1d7837fe37dd203763178df3325ff8b24abbd)
This didn't make any sense, and was already handled by pushing a new
execution context anyway.
By simply removing these bogus lines of code, we fix a bug where
throwing inside a function whose bytecode was shorter than the calling
function would crash trying to generate an Error stack trace (because
the bytecode offset we were trying to symbolicate was actually from
the longer caller function, and not valid in the callee function.)
This makes --log-all-js-exceptions less crash prone and more helpful.
(cherry picked from commit b3f77e47690cfd07058d824ea6f0b652489778bf)
- Expose table from console object
- Add new Table log level
- Create a JS object that represents table rows and columns
- Print table as HTML using WebContentConsoleClient
(cherry picked from commit 785180dd45ef6dcce4d847e564eca52ed0ad955b)
The proposal reached stage 4 and was merged into the ECMA-262 spec. See:
https://github.com/tc39/ecma262/commit/44bb0e0
(cherry picked from commit bf3e7d3ac43a16a8183b03c299b88702f493af82)
Loading Ladybird on Github results in 37 debug logs about being unable
to parse an empty Date string. This log is intended to catch Date
formats we do not support to detect web compatability problems, which
makes this case not particuarly useful to log.
Instead of trying to parse all of the different date formats and
logging that the string is not valid, let's just return NAN immediately.
(cherry picked from commit ee35e93eb23996923db12f39ba17ece61da4e39b)
We were already caching UTF-8 and byte strings, so let's add a cache
for UTF-16 strings as well. This is particularly profitable whenever we
run regular expressions, since the output of regex execution is a set of
UTF-16 strings.
Note that this is a weak cache like the other JS string caches, meaning
that strings are removed from the cache as they are garbage collected.
This avoids billions of PrimitiveString allocations across a run of WPT,
significantly reducing GC activity.
(cherry picked from commit 206479b2b5fc2641a619eb0d05c1185d869ef844)
1.25x speed-up on this microbenchmark:
let o = { get x() { return 1; } };
for (let i = 0; i < 10_000_000; ++i)
o.x;
I looked into this because I noticed getter invocation when profiling
long-running WPT tests. We already had the mechanism for non-getter
properties, and the change to support getters turned out to be trivial.
(cherry picked from commit 3c5819a6d27883907237bf8137fd4dc24ed04e72)
This allows date strings like "01 February 2013" to be parsed.
auth0.com also loads now because of this :^)
Add test for date parsing
(cherry picked from commit 179641a297ab0b4bafcce3a6361be2c4ed0c51ea)
This lets us log when our Date.parse implementation was unable to handle
a string found on the web.
(cherry picked from commit 8d6f36f8d6c0aea0253df8c84746f8c99bf79b4d)
C++ will jovially select the implicit conversion operator, even if it's
complete bogus, such as for unknown-size types or non-destructible
types. Therefore, all such conversions (which incur a copy) must
(unfortunately) be explicit so that non-copyable types continue to work.
This to avoid clashing with the GCC typeof extension, which apparently
confuses clang-format.
(cherry picked from commit 14beda00c9e823dd34da74e7d8fdf46aa57e845c)
The typeof operator has a very small set of possible resulting strings,
so let's make it much faster by caching those strings on the VM.
~8x speed-up on this microbenchmark:
for (let i = 0; i < 10_000_000; ++i) {
typeof i;
}
(cherry picked from commit d0b11af3876a64e6b254b5fc3f474d9bbe552024)
The spec allows setting a constructor on non built-in Iterator objects.
This is a normative change in the Iterator Helpers proposal. See:
https://github.com/tc39/proposal-iterator-helpers/commit/30b3501
(cherry picked from commit fb228a3d850eb5e4b06550823755719a377b41e6)
The spec allows setting the prototype on non built-in Iterator objects.
This is a normative change in the Iterator Helpers proposal. See:
https://github.com/tc39/proposal-iterator-helpers/commit/30b3501
(cherry picked from commit 734e37442db4419b58228e25702bfe176e52f5e3)
The JS::Error types all store their exception messages as a String. So
by using ByteString, we hit the StringView constructor, and end up
allocating the same string twice.
(cherry picked from commit c3f8202d0ca7761caaabf0af5f413dc25337801f)
When compiling with `-O2 -g1` optimizations (as done in the main
Serenity build), no out-of-line definitions end up emitted for
`Value::to_numeric`, causing files that reference the function but don't
include the definition from `ValueInlines.h` to add an undefined
reference in LibJS.so.
Properties marked with the [[Unimplemented]] attribute behave as normal
but invoke the `VM::on_unimplemented_property_access callback` when
they are accessed.
(cherry picked from commit 88d425f32b3b49d5dfa8d86e6e4e2c263cd450d4)
