When someone calls PrimitiveString::utf16_string() on a rope string,
we know for sure that the client wants a UTF-16 string and may not
be interested in a UTF-8 version at all.
To avoid round-tripping through UTF-8 in this scenario, callers can
now inform resolve_rope_if_needed() about their preferred encoding,
should rope resolution take place. The UTF-16 case is actually a lot
simpler than the UTF-8 case, since we can simply ask for UTF-16 data
for each fiber of the rope, and then concatenate all the fibers.
Since LibJS always uses UTF-16 for regular expression matching, this
avoids round-tripping through UTF-8 whenever the input to a regex test
is already UTF-16. :^)
The RegExpLiteral AST node already has the parsed regex::Parser::Result
so let's plumb that over to the bytecode executable instead of reparsing
the regex every time NewRegExp is executed.
~12% speed-up on language/literals/regexp/S7.8.5_A2.1_T2.js in test262.
This optimization was no longer helpful after the bug fix for missing
invalidation on global delete was introduced in 331f6a9e6, since we
now have to check bindings for presence in the global environment every
time anyway.
Since the bytecode VM now has fast GetGlobal in most cases, let's not
even worry about this and just remove the unhelpful "optimization".
In fact, removing this is actually an *optimization*, since we avoid
a redundant has_binding() check on every global variable access. :^)
Using mmap was quite punishing on inputs with lots of basic blocks,
such as test262 tests with eval() in a loop that goes 64k times..
~27% speed-up on language/literals/regexp/S7.8.5_A2.1_T2.js but
presumably everything everywhere will benefit from this. :^)
This change speeds up the process of checking variable declaration
within the scope by replacing the iteration through all declared
variables (without the ability to exit early from the loop) with hash
map lookups.
This change cuts google maps loading by 17s on my computer.
Using a special instruction to access global variables allows skipping
the environment chain traversal for them and going directly to the
module/global environment. Currently, this instruction only caches the
offset for bindings that belong to the global object environment.
However, there is also an opportunity to cache the offset in the global
declarative record.
This change results in a 57% increase in speed for
imaging-gaussian-blur.js in Kraken.
This counter is incremented whenever a mutating operation occurs
within the environment's set of bindings.
It is going to be used by GetGlobal instruction to correctly invalidate
cache when global declarative environment is mutated.
Cell::heap() and Cell::vm() needed to access member functions from
HeapBlock, and wanted to be inline, so they were moved to VM.h.
That approach will no longer work with VM.h not being included in every
file (starting from the next commit), so this commit fixes that circular
import issue by introducing secondary base classes to host the
references to Heap and VM, respectively.
Since we can't rely on shape identity (i.e its pointer address) for
unique shapes, give them a serial number that increments whenever a
mutation occurs.
Inline caches can then compare this serial number against what they
have seen before.
When building an object from an object expression, we don't want to
go through the full property setting machinery. This patch adds a new
PropertyKind::DirectKeyValue for PutById which guarantees that the
property becomes an own property.
This fixes an issue where setting the "__proto__" property in object
expressions wasn't working right.
12 new passes on test262. :^)
The instructions GetById and GetByIdWithThis now remember the last-seen
Shape, and if we see the same object again, we reuse the property offset
from last time without doing a new lookup.
This allows us to use Object::get_direct(), bypassing the entire lookup
machinery and saving lots of time.
~23% speed-up on Kraken/ai-astar.js :^)
This function now takes an optional out parameter for callers who would
like to what kind of property we ended up getting.
This will be used to implement inline caching for property lookups.
Also, to prepare for adding more forms of caching, the out parameter
is a struct CacheablePropertyMetadata rather than just an offset. :^)
Previously, the usage of local variables was limited for all function
declarations. This change relaxes the restriction and only prohibits
locals for hoistable annexB declarations.
Since it is not possible for delete operator to return true when it is
applied to local variable, DeleteVariable can safely always return
false for locals.
This also fixes operators/delete-local-variable.js in test-js.
Initially, the usage of local variables for parameters had to be
disabled when default values were used because there was a bug that
didn't allow to correctly find the scope to which identifiers used
within the default parameter expression belonged, and hence correctly
identify if a variable can be local. However, this bug was fixed in
2f85faef0f, so now this restriction
is no longer needed.
This change fixes an issue where identifiers used in default function
parameters were being "registered" in the function's parent scope
instead of its own scope. This bug resulted in incorrectly detected
local variables. (Variables used in the default function parameter
expression should be considered 'captured by nested function'.)
To resolve this issue, the function scope is now created before parsing
function parameters. Since function parameters can no longer be passed
in the constructor, a setter function has been introduced to set them
later, when they are ready.
Since AST interpreter switches to bytecode to execute generator
functions, arguments stored in local variables always need to be
initialized for such functions.
Using local variables to store function parameters makes Kraken tests
run 7-10% faster.
For now this optimization is limited to only be applied if:
- Parameter does not use destructuring assignment
- None of the function params has default value
- There is no access to "arguments" variable inside function body
Converting a base value to an Object is performed by Reference::delete_.
Doing this early in the bytecode operator could be observable, although
it would likely be the first observable step in Reference::delete_
anyways. This will just align these operators with upcoming operators
for super references, where doing this coercion first will be observable
(we need to throw an exception for deleting a super property before this
coercion).
This is (part of) a normative change in the ECMA-262 spec. See:
d09532c
We recently implemented other parts of that commit in LibJS, but missed
this change:
442ca4f9b42b19d1b5ab
These are not strictly unresolvable references. Treating them as such
fails an assertion in the `delete UnaryExpression` semantic (which is
Reference::delete_ in our implementation) - we enter the unresolvable,
branch, which then asserts that the [[Strict]] slot of the reference is
false.
Invariants 5 and 6 of the `EnumerateObjectProperties` AO mean that we
must not include an enumerate property if there is a non-enumerable
property higher up the prototype chain with the same name. The previous
implementation did not adhere to this, as `EnumerableOwnPropertyNames`
does not carry information about present but non-enumerable properties.
This is part of an old normative change that happened soon after
Andreas made `super` closer to spec in 1270df2.
See https://github.com/tc39/ecma262/pull/2267/
This was introduced into bytecode by virtue of copy and paste :^)
Bytecode results:
Summary:
Diff Tests:
+2 ✅ -2 ❌
