Update to the latest version of the spec which was refactored to use
time zone methods record. This requires updating a whole bunch of
callers to pass through a record too.
This also ends up improving exceptions on a missing
getOffsetNanosecondsFor method.
`var` declarations can have duplicates, but duplicate `let` or `const`
bindings are a syntax error.
Because of this, we can sink `let` and `const` directly into the
preferred_dst if available. This is not safe for `var` since the
preferred_dst may be used in the initializer.
This patch fixes the issue by simply skipping the preferred_dst
optimization for `var` declarations.
Instead of looking these up in the VM execution context stack whenever
we need them, we now just cache them in the interpreter when entering
a new call frame.
Comparing two Values has to call the generic same_value() helper,
and we can avoid this by simply using a stronger type for built-in
native function handlers.
The exisiting fast path only permits for valid i32 values.
On https://cyxx.github.io/another_js, this eliminates the runtime of
typed_array_set_element, and reduces the runtime of put_by_value from
11.1% to 7.7%.
This reverts commit 9c943f36ed.
This optimization is superseded by optimizing IsValidIntegerIndex for
TypedArrays with non-resizable ArrayBuffers. Reverting this commit has
no impact on test-js, test262, or live website performance.
This reverts commit 5fd53652b7.
This optimization is superseded by optimizing IsValidIntegerIndex for
TypedArrays with non-resizable ArrayBuffers. Reverting this commit has
no impact on test-js, test262, or live website performance.
This reverts commit 72cee4c88b.
This optimization is superseded by optimizing IsValidIntegerIndex for
TypedArrays with non-resizable ArrayBuffers. Reverting this commit has
no impact on test-js, test262, or live website performance.
If we know the TA does not have a resizable ArrayBuffer, we can avoid
most of the heavy lifting that IsValidIntegerIndex performs.
On https://cyxx.github.io/another_js, this reduces the runtime of
IsValidIntegerIndex from 7.1% to 3.7%.
This avoids a virtual dispatch upon invoking the element size getter.
The size is static, so we could make TypedArrayBase templated with a
NTTP for the size, but let's not undergo such a wide-spread refactor.
On https://cyxx.github.io/another_js, this reduces the runtime of
IsValidIntegerIndex from 8.9% to 7.1%.
This avoids visiting the underlying buffer twice from ArrayBuffer's
byte_length.
On https://cyxx.github.io/another_js, this reduces the runtime of
IsValidIntegerIndex from 9.9% to 8.9%.
In IsValidIntegerIndex, we check if the TA is detached before invoking
MakeTypedArrayWithBufferWitnessRecord. There's no need to check it
again.
On https://cyxx.github.io/another_js, this reduces the runtime of
IsValidIntegerIndex from 10.7% to 9.9%.
In IsValidIntegerIndex, we check if the TA is detached before invoking
IsTypedArrayOutOfBounds. There's no need to check it again.
On https://cyxx.github.io/another_js, this reduces the runtime of
IsValidIntegerIndex from 11.5% to 10.7%.
Note: When we better support SharedArrayBuffer, that part of this AO
might not be inlined, as it looks a bit expensive.
On https://cyxx.github.io/another_js, this reduces the runtime of
IsValidIntegerIndex from 12.5% to 11.5%.
In IsValidIntegerIndex, we check IsTypedArrayOutOfBounds before invoking
TypedArrayLength. There's no need to check it again.
On https://cyxx.github.io/another_js, this reduces the runtime of
IsValidIntegerIndex from 16% to 12.5%.
This follows a change in the spec which refactored this function and its
callers to make use of a record instead of stuffing all of the possible
return values into a single Value.
As always in temporal land, this AO remains out of date, as well of all
its callers. Update all of these callers to the new API where possible,
and use an ad-hoc function to convert this struct back to a JS::Value
for APIs that have not been updated yet.
Similar to 'Calendar Methods Record', this is part of a refactor to the
temporal spec which will need much work for all of the corresponding AOs
to be updated to use.
Put in a new header file to prevent circular include problems when using
this new record.
Additionally, use the second bit (instead of the first) to differentiate
between strings and symbols there. This will allow transparent
conversion of DFS to StringBase in the future.
When compiling code like this:
x = { foo: x }
We don't want to put a new JS::Object in `x` until *after* we've
evaluated `x` for the `foo` field.
This fixes an issue when loading https://puter.com/ :^)
This works very similarly to MarkedVector<T>, but instead of expecting
T to be Value or a GC-allocated pointer type, T can be anything.
Every pointer-sized value in the vector's storage will be checked during
conservative root scanning.
In other words, this allows you to put something like this in a
ConservativeVector<Foo> and it will be protected from GC:
struct Foo {
i64 number;
Value some_value;
GCPtr<Object> some_object;
};
Instead of having Call refer to a range of VM registers, it now has
a trailing list of argument operands as part of the instruction.
This means we no longer have to shuffle every argument value into
a register before making a call, making bytecode smaller & faster. :^)
By handling common cases like Int32 arithmetic directly in the
instruction handler, we can avoid the cost of calling the generic helper
functions in Value.cpp.
Instead of splitting the postfix variants into ToNumeric + Inc/Dec,
we now have dedicated PostfixIncrement and PostfixDecrement instructions
that handle both outputs in one go.
This adapts our implementation to the editorial change in the temporal
proposal: 737baf2d
The changes to CalendarMethodsRecordLookup had already been implemented,
but we had followed the typo in the spec for CalendarMethodsRecordCall.
The issue in CalendarMethodsRecordCall hasn't surfaced yet, as the AOs
using Calendar Methods Record are currently not passing through a String
to represent a Calendar builtin.
No change to test-262.
This number is pure guesswork but it appears to fix GCC builds with
both ASAN and UBSAN hitting a native stack overflow before we have
a chance to catch it on our Azure CI.
This patch moves us away from the accumulator-based bytecode format to
one with explicit source and destination registers.
The new format has multiple benefits:
- ~25% faster on the Kraken and Octane benchmarks :^)
- Fewer instructions to accomplish the same thing
- Much easier for humans to read(!)
Because this change requires a fundamental shift in how bytecode is
generated, it is quite comprehensive.
Main implementation mechanism: generate_bytecode() virtual function now
takes an optional "preferred dst" operand, which allows callers to
communicate when they have an operand that would be optimal for the
result to go into. It also returns an optional "actual dst" operand,
which is where the completion value (if any) of the AST node is stored
after the node has "executed".
One thing of note that's new: because instructions can now take locals
as operands, this means we got rid of the GetLocal instruction.
A side-effect of that is we have to think about the temporal deadzone
(TDZ) a bit differently for locals (GetLocal would previously check
for empty values and interpret that as a TDZ access and throw).
We now insert special ThrowIfTDZ instructions in places where a local
access may be in the TDZ, to maintain the correct behavior.
There are a number of progressions and regressions from this test:
A number of async generator tests have been accidentally fixed while
converting the implementation to the new bytecode format. It didn't
seem useful to preserve bugs in the original code when converting it.
Some "does eval() return the correct completion value" tests have
regressed, in particular ones related to propagating the appropriate
completion after control flow statements like continue and break.
These are all fairly obscure issues, and I believe we can continue
working on them separately.
The net test262 result is a progression though. :^)
This is pure prep work for refactoring the bytecode to use more operands
instead of only registers.
generate_bytecode() virtuals now return an Optional<Operand>, and the
idea is to return an Operand referring to the value produced by this
AST node.
They also take an Optional<Operand> "preferred_dst" input. This is
intended to communicate the caller's preference for an output operand,
if any. This will be used to elide temporaries when we can store the
result directly in a local, for example.
The JIT compiler was an interesting experiment, but ultimately the
security & complexity cost of doing arbitrary code generation at runtime
is far too high.
In subsequent commits, the bytecode format will change drastically, and
instead of rewriting the JIT to fit the new bytecode, this patch simply
removes the JIT instead.
Other engines, JavaScriptCore in particular, have already proven that
it's possible to handle the vast majority of contemporary web content
with an interpreter. They are currently ~5x faster than us on benchmarks
when running without a JIT. We need to catch up to them before
considering performance techniques with a heavy security cost.
