At the moment when the static private method is unused
in source code (either explicitly or through eval) but is accessed
at runtime through the debugger, and there are no other potential
references to the class variable in the source code otherwise,
the reference to the class variable is lost here since the class
variable would not be context-allocated, then we could not rebuild
a proper brand check for it.
For now, a ReferenceError would be thrown and the method is considered
"optimized away", similar to how unused ordinary methods in closures
work. Before this patch it would DCHECK when generating bytecode
for the debugger instead of throwing errors.
Bug: v8:9839, v8:8330
Change-Id: I5d63131a7bdba141d01a3e6459bc27d0f5953c1a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2095637
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66734}
The interpreter's finalization was accidentally double-counting compile
finalizations, which manifested as a Compile count increase. As a side
effect, this would also miscount off-thread finalizations as main-thread
finalizations -- not a problem yet, but would be one in the future.
Bug: chromium:1011762
Bug: chromium:1060927
Change-Id: I37232bbd46c8cba80c0b413638f43d83d5313e70
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098727
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66679}
This CL is a step towards making StackChecks implicit. In a follow-up CL
said StackChecks will become implicit within JumpLoops.
Cq-Include-Trybots: luci.chromium.try:linux-rel
Bug: v8:10149, v8:9960
Change-Id: I5ae247be3f7a58ccdf86398cace30724715767a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062391
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66668}
This CL merges nested loops that share the same header offset with its
parent loop, by not emitting JumpLoop bytecode for these inner loops.
Instead, we generate a Jump to its parent's JumpToHeader (which in
turn can be a JumpLoop or another Jump to its parent's JumpToHeader).
Originally, every loop had a unique first Bytecode to jump to. Since
IterationBody StackChecks are going to become implicit this will no
longer be the case.
As a note, this CL just sets the foundation that the follow-up CLs
will build on top of. Since we have explicit StackChecks, and they
are at the beginning of loops we do not have nested loops as of now.
Bug: v8:10149, v8:9960
Change-Id: I6daee4d2c6d6216f022228c87c4aa74e163997b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062390
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66626}
String::NewFromLiteral is a templated function that takes a char[N]
argument that can be used as an alternative to String::NewFromUtf8 and
returns a Local<String> rather than a MaybeLocal<String> reducing the
number of ToLocalChecked() or other checks.
Since the string length is known at compile time, it can statically
assert that the length is less than String::kMaxLength, which means that
it can never fail at runtime.
This also converts all found uses of NewFromUtf8 taking a string literal
or a variable initialized from a string literal to use the new API. In
some cases the types of stored string literals are changed from const
char* to const char[] to ensure the size is retained.
This API does introduce a small difference compared to NewFromUtf8. For
a case like "abc\0def", NewFromUtf8 (using length -1 to infer length)
would treat this as a 3 character string, whereas the new API will treat
it as a 7 character string.
As a drive-by fix, this also fixes all redundant uses of
v8::NewStringType::kNormal when passed to any of the String::New*
functions.
Change-Id: Id96a44bc068d9c4eaa634aea688e024675a0e5b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089935
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66622}
This CL simplifies IC code since we no longer need to keep
feedback slot indices in both Smi and IntPtr form and as
a result it should improve overall performance of --no-opt
mode on Octane by ~1%.
Bug: v8:10047
Change-Id: Ib717697cdb805c9f93286e9c62ee8a63361d3560
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1965586
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66585}
When an empty class is nested inside a class with private instance
methods, like this:
class Outer {
constructor() {}
#method() {}
factory() {
class Inner {
constructor() { }
}
return Inner;
}
run(obj) {
obj.#method();
}
}
The bytecode generator previously generate private brand
initialization for the constructor of Inner by mistake,
because during scope chain serialization/deserialization,
the outer scopes of Inner and factory() are not allocated
or serialized (as they are empty). In the eyes of the bytecode
generator, it then appeared as if Outer is the direct outer
scope of Inner's constructor.
In order to work around this information loss, in this patch
we rely on SharedFunctionInfo instead of the Context/ScopeInfo
chain to maintain the information about private brand initialization.
This is done by shrinking expected_nof_properties to 8 bits and
freeing 8 bits for a second bitfield on the SFI.
Design doc: https://docs.google.com/document/d/14maU596YbHcWR7XR-_iXM_ANhAAmiuRlJZysM61lqaE/edit#
Bug: v8:9839, v8:8330, v8:10098
Change-Id: I4370a0459bfc0da388052ad5a91aac59582d811d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2056889
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66575}
Add the remaining missing templatizations to allow an initial wiring in
of the off-thread factory into streaming compilation finalization.
The off-thread finalization is behind a flag, disabled by default:
--finalize-streaming-on-background
When the flag is enabled, background tasks will perform perform the
finalization during their background execution, and will release the
parser and compilation jobs once they are no longer needed.
The implementation is complete enough for performance testing, but not
enough for launch. Notably, there is no support for:
* Class boilerplates (the code is marked unreachable),
* Exceptions during finalization, i.e. parse/compile warnings/errors,
* Allocation sampling,
* Logging,
* Asm.js,
* Parallel complication tasks
* Forced source positions (for "NeedsDetailedOptimizedCodeLineInfo()")
This patch also adds some tracing events for the various stages of the
off-thread finalization (including the main-thread merge) for further
performance improvements.
Bug: chromium:1011762
Change-Id: Ia44fa56975dd689f0d92c1543b294cdb063eb199
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066965
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66566}
Remove OffThreadHandle, HandleOrOffThreadHandle, and HandleFor, and
make the OffThreadIsolate allocate "real" Handles. Rather than using
the main-thread Isolate's handle scopes, these off-thread Handles are
backed by a Zone, which is tied to the lifetime of the nearest
OffThreadHandleScope. Eventually, we'll likely want to merge the
implementation of OffThreadHandleScope and HandleScope, but currently
the latter is too tightly coupled to the main thread to do so.
Bug: chromium:1011762
Change-Id: I2a6361931fe3f90a7bef4cc28ee42155fa8d062f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071865
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66516}
We can make better inlining decisions in TurboFan if the CallIC will
provide the feedback that it's seen multiple closures that share the
same SharedFunctionInfo. This is not difficult to do, and it fixes
some frustrating performance cliffs.
Thanks to Bmeurer@chromium.org for the prototype CL, rebased from his
project a year ago.
Bug: v8:2206, v8:10100
Change-Id: I4248145ea67216f9a23efa175bbe90e7a9ee0ec4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2054100
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66512}
We use the same interrupt to both allocate feedback vectors and
for updating the profiler ticks. If there is a feedback vector already
available, we just increment the profiler ticks that we use to mark
for optimizing function. Calling JSFunction::EnsureFeedbackVector
allocates a feedback vector, but doesn't reset the budget, so we
optimize much earlier than expected. This is currently only a problem
with %PrepareFunctionForOptimize that doesn't reset the budget. Other
code paths do also reset the interrupt budget.
Bug: chromium:10243
Change-Id: I611a9202e5e71077bf897def5959bcfe11b8fdf4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064980
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66426}
After support for ARCH_PPC was dropped, it became a subset of
ARCH_PPC64. If you compile for ppc64, then you set the ARCH_PPC64
define which also sets the ARCH_PPC define.
To be able to again support ppc (32 bit) those defines should be
split up again.
This commit only splits up the defines but does not introduce a
working ARCH_PPC variant.
Bug: v8:10102
Change-Id: I64e0749f8e5a7dc078ee7890d92e57b82706a849
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1989826
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66390}
This fully tnodifies TryHasOwnProperty, TryLookupProperty,
CheckPrototypeEnumCache, CheckEnumCache and
ExtractFixedDoubleArrayFillingHoles.
CopyElementsOnWrite is also converted except for parameters passed with
ParameterMode.
Also fixes the type of TryLookupProperty, which fails tests if the
object parameter is actually forced to be JSReceiver.
Bug: v8:10155
Change-Id: I3a925f1fd3f8a1b610d63d08a49af48ef6da505c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064979
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66373}
This allows CoverageInfo to be distinguished from other kinds of
FixedArray at runtime. I also updated it to use untagged data since it
only stores ints, since that seems like the generally right thing to do
(even though I doubt anybody allocates enough of these to notice the
reduced GC work).
Related Torque changes:
- Allow structs containing untagged data to be used as class fields.
This requires classifying them into the tagged or untagged sections of
the class layout, and checking that their alignment requirements are
met when stored in a packed array.
- Generate a struct containing struct field offsets, so we can ensure
that the layouts defined in Torque and C++ code match. Of course it
would be nice to generate a lot more (indexed accessors, synchronized
accessors, GC visitors, etc.), but we can't do it all at once.
Change-Id: I29e2a2afe37e4805cd80e3a84ef9edfe7ca7bb6b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2047399
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#66318}
REPL 'let' declared variables use VariableLocation::REPL_GLOBAL which
was not handled by a switch in the bytecode generator. The default
case ran into an UNREACHABLE.
This CL fixes this by properly handling VariableLocation::REPL_GLOBAL
for delete.
Drive-by: Replaced the default case with an explicit case for
VariableLocation::MODULE.
Bug: chromium:1052721
Change-Id: I1330ff2f2c6f042a596a8298599a5d58769894f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2060488
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66301}
FunctionEntry StackChecks is one of the two cases where we generate a
StackCheck bytecode. In these cases, we do stack check against the js
limit (not to be confused with the real js limit). Their purpose is to
be able to interrupt the running code.
We can omit the FunctionEntry StackCheck by embedding its code into
the InterpreterEntryTrampoline builtin. We save one bytecode per
interpreted function.
This change has rippling effects for optimized code, as well as the
deoptimizer.
Bug: v8:10149, v8:9977, v8:9960
Change-Id: I6156de48b3bc0b519dd21190a8e6214fbe96c78d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914218
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66206}
The Factory/OffThreadFactory allows us to cleanly separate object
construction behaviour between main-thread and off-thread in a
syntactically consistent way (so that methods templated on the factory
type can be made to work on both).
However, there are cases where we also have to access the Isolate, for
handle creation or exception throwing. So far we have been pushing more
and more "customization points" into the factories to allow these
factory-templated methods to dispatch on this isolate behaviour via
these factory methods. Unfortunately, this is an increasing layering
violation between Factory and Isolate, particularly around exception
handling.
Now, we introduce an OffThreadIsolate, analogous to Isolate in the same
way as OffThreadFactory is analogous to Factory. All methods which were
templated on Factory are now templated on Isolate, and methods which
used to take an Isolate, and which were recently changed to take a
templated Factory, are changed/reverted to take a templated Isolate.
OffThreadFactory gets an isolate() method to match Factory's.
Notably, FactoryHandle is changed to "HandleFor", where the template
argument can be either of the Isolate type or the Factory type (allowing
us to dispatch on both depending on what is available).
Bug: chromium:1011762
Change-Id: Id144176f7da534dd76f3d535ab2ade008b6845e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030909
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66101}
This changes how we setup modules from being entirely bytecode based to a
single fixed array with metadata that's passed into a runtime function
DeclareModuleExports, similar to DeclareGlobals. This is preperatory work to
replace the bytecode that calls those functions with explicit calls before we
even start running the code. In the case of modules that will obviate the need
for modules to be generators.
Change-Id: Ibf1c913a9dc78041e3001b174c66ab89226d9c8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030733
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66097}
Changing script context handling from bytecode based to metadata on the
function. This fixes the debugger to explicitly check the code rather
than implicitly relying on a NewScriptContext bytecode causing side
effects.
Bug: chromium:1043151
Tbr: ulan@chromium.org
Change-Id: I38c5c04d7c76155e0a055ae6efd57f25986bdb7d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013117
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65920}
That way we don't need to generate bytecode for it.
Change-Id: Ie7e17f283cf5a096ab98c4fd01fd346b56b83576
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2004611
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65832}
Add support for internalizing an AstValueFactory using the off-thread
factory. Includes adding ConsString support to OffThreadFactory.
This introduces a Handle union wrapper, which is used in locations that
can store a Handle or an OffThreadHandle. This is used in this patch for
the internalized "string" field of AST strings, and will be able to be
used for other similar fields in other classes (e.g. the ScopeInfo
handle in Scope, object boilerplate descriptor handles, the inferred
name handle on FunctionLiterals, etc.). It has a Factory-templated
getter which returns the appropriate handle for the factory, and a
debug-only tag to make sure the right getter is used at runtime. This
union wrapper currently decomposes implicitly to a Handle if the getter
is not called, to minimise code changes, but this implicit conversion
will likely be removed for clarity.
Bug: chromium:1011762
Change-Id: I5dd3a7bbdc483b66f5ff687e0079c545b636dc13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993971
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65816}
This way we don't need to generate bytecodes to push the context.
This drops the stack trace for redeclaration SyntaxErrors but keeps the
message location. This is in line with what we do for other
SyntaxErrors.
Change-Id: Id8e3cc348b4d56a8196753baf51cfd810f07512b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997439
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65810}
This Tnodifies the CombineFeedback and OverwriteFeedback methods and
changes the TaggedToWord32OrBigInt* ann TaggedToNumeric methods to take
TVariables.
Additionally it refactors bitwise binary operators in
intepreter-generator.cc and builtins-number-gen.cc and puts the common
code in NumberBuiltinsAssembler.
Bug: v8:10021
Change-Id: I3b15ecfadb42b50ffbfd0bd1114197e0fef42e99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1995387
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65762}
This makes the code a little more specific to what's happening: There is only 1
global scope, and if there is one, we know its declarations are
info->scope()->declarations(). That means we don't need multiple
GlobalDeclarationsBuilders, and we don't need to cache partially serialized
versions of the declarations. One builder is enough, and we can simply walk
those declarations if there are any.
Additionally this CL drops unnecessary information passed into DeclareGlobals:
- Global functions always have the name on the shared function info, so we can
drop the name.
- Due to lazy feedback vectors there's no point in trying to preinitialize
global loads. Also this was only preinitializing global loads at the script
level, not sub functions; without even checking whether the global load was
used. It may actually have caused us to do more work and allocate more global
load feedback slots than neccessary.
Change-Id: Ibbdd029abe5a39ba27f7fc9be84670c5d444d98d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997123
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65725}
This change moves the definitions of the bitfield flags used by Symbol
and Map to Torque. Symbol could directly follow the pattern established
by SharedFunctionInfo, but Map required some other changes:
- Until now, Torque bitfield definitions have required unsigned types. I
thought that this would be the least-surprising behavior, since we
never sign-extend when decoding bitfield values. However, I believe
that the amount of churn involved in making ElementsKind be unsigned
outweighs the benefit we were getting from this restriction (and
similar difficulties are likely to arise in converting other bitfield
structs to Torque), so this CL updates Torque to allow signed bitfield
values.
- If we try to make Map extend from all of the generated classes that
define its flags, we end up with class sizing problems because some
compilers only apply empty base class optimization to the first in a
row of empty base classes. We could work around this issue by
generating macros instead of classes, but I took this as an
opportunity for a minor clean-up instead: rather than having bitfield
definitions for several different bitfield structs all jumbled
together in Map, they can be split up. I think this makes the code a
little easier to follow, but if others disagree I'm happy to implement
macro generation instead.
Change-Id: Ibf339b0be97f72d740bf1daa8300b471912faeba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1988934
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#65701}
Remove the explicit script handle from ParseInfo, and make it either
a Handle that is passed around where needed, or one inferred from the
SharedFunctionInfo.
This will be useful for compilation finalization using the off-thread
factory, which will not generate real Handles since it has no access
to the Isolate.
Bug: chromium:1011762
Change-Id: I5d9564009ec83bb9fc74191b4aa69735d132c2f7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1977861
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65629}
Converts StoreObjectField, StoreMapNoWriteBarrier and
StoreObjectFieldRoot to use TNode parameters and convert all of their
uses.
Bug: v8:10021
Change-Id: Ic0511e43677f6aaaeac20df58a69be74156d390f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1980581
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65605}
Makes the Node* versions private so they can still be called from the
inlined TNode versions.
Also changes to LoadFromParentFrame to return TNode<Object> since its
uses don't require anything looser.
Bug: v8:10021
Change-Id: I84e3831d444a7787e0b03ff2f9e665181a9caa06
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1980578
Commit-Queue: Dan Elphick <delphick@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65604}
The receiver may be undefined when calling optionally chained
properties, so CallAnyReceiver should be used instead of CallProperty.
TBR=rmcilroy@chromium.org
Bug: chromium:1038178
Change-Id: Id91f2ecda1a5b38f6d1c9a6b6f90c0ae7dcbe638
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1986205
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65580}
This reverts commit 91e3243d60.
Reason for revert: This deopts to the wrong point.
Original change's description:
> Extend GetIterator bytecode to perform JSReceiver check on object[Symbol.iterator]()
>
> Current GetIterator bytecode loads and calls @@iterator property on a
> given object. This change extends the bytecode functionality to check
> whether the value returned after calling @@iterator property is a valid
> JSReceiver. The bytecode throws SymbolIteratorInvalid exception if the
> returned value is not a valid JSReceiver. This change absorbs the
> functionality of additional two bytecodes - JumpIfJSReceiver and
> CallRuntime, that are part of the iterator protocol in the GetIterator
> bytecode.
>
> Bug: v8:9489
> Change-Id: I9e84cfe85eeb9a1b8a97ca0595375ac26ba1bbfd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792905
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
> Cr-Commit-Position: refs/heads/master@{#63704}
TBR=rmcilroy@chromium.org,leszeks@chromium.org,tebbi@chromium.org,swapnilgaikwad@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:9489
Change-Id: I9324b5b01ead29912ad793a1e7b4d009643d7901
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1960288
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65541}
This reverts commit 5377e72c0e.
Reason for revert: Looks like the relevant graphs didn't recover after
this revert, which suggests that the regression was an unrelated
secondary effect. Relanding the original change since the revert did
cause some microbenchmark regressions.
Original change's description:
> Revert "[ic] Load name/context lazily in LdaNamedProperty"
>
> This reverts commit 347092ac2b.
>
> Not a clean revert, since other changes got baked on top, but rather
> a manual removal of LoadLazyICParameters.
>
> Reason for revert: Seems to actually regress bindings perf tests (see
> bugs and https://chromeperf.appspot.com/group_report?rev=62539), doesn't
> seem to improve performance elsewhere, and increases complexity.
>
> Original change's description:
> > [ic] Load name/context lazily in LdaNamedProperty
> >
> > Introduces LazyLoadICParameters which allow a LazyNode for context and
> > name. These aren't used on the fast path, so we want to avoid reading
> > them for both performance and register pressure reasons.
> >
> > Change-Id: Ifb637cf4782ce984feee9af503998e7539beb823
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1686665
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#62539}
>
> # Not skipping CQ checks because original CL landed > 1 day ago.
>
> Bug: chromium:981797
> Bug: chromium:982630
> Change-Id: I88af764d17afb76d6e64b95a3d1e4aaa1c6c8978
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1934327
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65205}
TBR=leszeks@chromium.org,verwaest@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:981797, chromium:982630, v8:10059
Change-Id: I13754de06c83439e03e22cfaa7a14ce454076db9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1973730
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65499}
This is a reland of 5bddc0e142
The original CL was speculatively reverted as it was suspected to
cause failures on the non-determinism bot. This was ultimately
confirmed to not be the case, so this CL is safe to reland as-is.
Original change's description:
> Implement top-level await for REPL mode
>
> Design doc: bit.ly/v8-repl-mode
>
> This CL allows the usage of 'await' without wrapping code in an async
> function when using REPL mode in global evaluate. REPL mode evaluate
> is changed to *always* return a Promise. The resolve value of the
> promise is the completion value of the REPL script.
>
> The implementation is based on two existing mechanisms:
> - Similar to async functions, the content of a REPL script is
> enclosed in a synthetic 'try' block. Any thrown error
> is used to reject the Promise of the REPL script.
>
> - The content of the synthetic 'try' block is also re-written the
> same way a normal script is. This is, artificial assignments to
> a ".result" variable are inserted to simulate a completion
> value. The difference for REPL scripts is, that ".result" is
> used to resolve the Promise of the REPL script.
>
> - ".result" is not returned directly but wrapped in an object
> literal: "{ .repl_result: .result}". This is done to prevent
> resolved promises from being chained and resolved prematurely:
>
> > Promse.resolve(42);
>
> should evaluate to a promise, not 42.
>
> Bug: chromium:1021921
> Change-Id: I00a5aafd9126ca7c97d09cd8787a3aec2821a67f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1900464
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65273}
TBR: yangguo@chromium.org,verwaest@chromium.org
Bug: chromium:1021921
Change-Id: I95c5dc17593161009a533188f91b4cd67234c32f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1954388
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65360}
This patch implements inspector support for private instance methods:
- Previously to implement brand checking for instances with private
instance methods we store the brand both as the value with the brand
itself as the key in the stances. Now we make the value the context
associated with the class instead.
- To retrieve the private instance methods and accessors from the
instances at runtime, we look into the contexts stored with the
brands, and analyze the scope info to get the names as well as
context slot indices of them.
- This patch extends the `PrivatePropertyDescriptor` in the inspector
protocol to include optional `get` and `set` fields, and make the
`value` field optional (similar to `PropertyDescriptor`s).
Private fields or private instance methods are returned in the
`value` field while private accessors are returned in the `get`
and/or `set` field. Property previews for the instaces containing
private instance methods and accessors are also updated similarly,
although no additional protocol change is necessary since the
`PropertyPreview` type can already be used to display accessors.
Design doc: https://docs.google.com/document/d/1N91LObhQexnB0eE7EvGe57HsvNMFX16CaWu-XCTnnmY/edit
Bug: v8:9839, v8:8330
Change-Id: If37090bd23833a18f75deb1249ca5c4405ca2bf2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1934407
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65337}
This reverts commit 5bddc0e142.
Reason for revert: Possible culprit for https://bugs.chromium.org/p/chromium/issues/detail?id=1029863
Original change's description:
> Implement top-level await for REPL mode
>
> Design doc: bit.ly/v8-repl-mode
>
> This CL allows the usage of 'await' without wrapping code in an async
> function when using REPL mode in global evaluate. REPL mode evaluate
> is changed to *always* return a Promise. The resolve value of the
> promise is the completion value of the REPL script.
>
> The implementation is based on two existing mechanisms:
> - Similar to async functions, the content of a REPL script is
> enclosed in a synthetic 'try' block. Any thrown error
> is used to reject the Promise of the REPL script.
>
> - The content of the synthetic 'try' block is also re-written the
> same way a normal script is. This is, artificial assignments to
> a ".result" variable are inserted to simulate a completion
> value. The difference for REPL scripts is, that ".result" is
> used to resolve the Promise of the REPL script.
>
> - ".result" is not returned directly but wrapped in an object
> literal: "{ .repl_result: .result}". This is done to prevent
> resolved promises from being chained and resolved prematurely:
>
> > Promse.resolve(42);
>
> should evaluate to a promise, not 42.
>
> Bug: chromium:1021921
> Change-Id: I00a5aafd9126ca7c97d09cd8787a3aec2821a67f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1900464
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65273}
TBR=yangguo@chromium.org,leszeks@chromium.org,verwaest@chromium.org,szuend@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1021921
Change-Id: I9eaea584e2e09f3dffcbbca3d75a3c9bcb0a1adf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1948719
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65333}
Design doc: bit.ly/v8-repl-mode
This CL allows the usage of 'await' without wrapping code in an async
function when using REPL mode in global evaluate. REPL mode evaluate
is changed to *always* return a Promise. The resolve value of the
promise is the completion value of the REPL script.
The implementation is based on two existing mechanisms:
- Similar to async functions, the content of a REPL script is
enclosed in a synthetic 'try' block. Any thrown error
is used to reject the Promise of the REPL script.
- The content of the synthetic 'try' block is also re-written the
same way a normal script is. This is, artificial assignments to
a ".result" variable are inserted to simulate a completion
value. The difference for REPL scripts is, that ".result" is
used to resolve the Promise of the REPL script.
- ".result" is not returned directly but wrapped in an object
literal: "{ .repl_result: .result}". This is done to prevent
resolved promises from being chained and resolved prematurely:
> Promse.resolve(42);
should evaluate to a promise, not 42.
Bug: chromium:1021921
Change-Id: I00a5aafd9126ca7c97d09cd8787a3aec2821a67f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1900464
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65273}
Correctly passing the receiver depends on the Call AST node's type.
Calling a parenthesized optional chain expression is parsed as a Call of
an OptionalChain of a Property. Currently the computation of the type
does not take optional chains of property loads into consideration, so
calls of parenthesized optional chain expressions always get passed an
undefined receiver.
Bug: v8:10024
Change-Id: I904b0eeca2df30160def674fb32adf821403aef9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1938571
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65252}
This reverts commit 347092ac2b.
Not a clean revert, since other changes got baked on top, but rather
a manual removal of LoadLazyICParameters.
Reason for revert: Seems to actually regress bindings perf tests (see
bugs and https://chromeperf.appspot.com/group_report?rev=62539), doesn't
seem to improve performance elsewhere, and increases complexity.
Original change's description:
> [ic] Load name/context lazily in LdaNamedProperty
>
> Introduces LazyLoadICParameters which allow a LazyNode for context and
> name. These aren't used on the fast path, so we want to avoid reading
> them for both performance and register pressure reasons.
>
> Change-Id: Ifb637cf4782ce984feee9af503998e7539beb823
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1686665
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62539}
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:981797
Bug: chromium:982630
Change-Id: I88af764d17afb76d6e64b95a3d1e4aaa1c6c8978
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1934327
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65205}
This was added in 2d889aa9a4 but all consumers of it have since been
removed.
Bug: v8:10021
Change-Id: I13aa12853e1720b2f919ca8b29737fedb96bc145
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1938462
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65198}
