They are a source of inconsistency and thus confusion.
Bug: v8:11371
Change-Id: Ia62f6800ad85576bed1cfe10e7ad044bdbf569af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692247
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72759}
For stack traces, especially all stack traces exposed via the Inspector
(i.e. for the purpose of async stack traces), JSFunction::GetDebugName()
is still a bottleneck, even after the removal of "displayName" support.
As outlined in https://bit.ly/devtools-function-displayName-removal a
follow-up optimization here would be to improve the performance of the
"name" lookup. Previously, it'd always use the LookupIterator combined
with JSReceiver::GetDataProperty(), which in the common case would find
the "name" property and the return undefined, since it doesn't invoke
getters on AccessorInfos, and eventually fall through to the actual
logic in SharedFunctionInfo::DebugName().
Now we had a similar situation with Function.prototype.bind(), which
also needs to lookup "name" on regular function objects quite often, and
what we implemented there is to just look into the DescriptorArray of
the incoming function object and see if the entry for the "name"
descriptor is still untouched (key is "name" and value is an
AccessorInfo), and if so completely bypass the slow-path lookup via the
LookupIterator.
With this CL (and the optimization in https://crrev.com/c/2695386), the
cost of symbolization is now significantly lower than the cost of the
actual stack trace capturing, for the async stack traces in the example
from https://crbug.com/1077657 as indicated by the perf profile below:
```
- 26.03% v8_inspector::AsyncStackTrace::capture
+ 17.34% v8::StackTrace::CurrentStackTrace
- 7.27% v8_inspector::(anonymous namespace)::toFramesVector
- 7.18% v8_inspector::V8Debugger::symbolize
- 6.27% v8_inspector::StackFrame::StackFrame
+ 2.52% v8_inspector::toProtocolString
+ 1.88% v8::internal::StackFrameInfo::GetLineNumber
0.78% operator new[]
0.55% operator new[]
```
Bug: chromium:1077657, v8:8742, chromium:1069425, chromium:1177685
Change-Id: I38f23816295f4381f5109cc78e4856dc0b67b097
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695593
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72758}
- Directly use the right target register for the "fast" case as temporary
register
- Don't load the function to load the feedback since that's unnecessary
by now
- Deduplicate the cell loading code
Bug: v8:11429
Change-Id: Ia2298315c2db6f228be0821687ff92859169dd97
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695588
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72755}
Previously we had cached the source position information on
JSStackFrame (C++) objects and reused that between calls to
GetLineNumber() and GetColumnNumber(). The refactoring in
https://crrev.com/eed0d27c2f774b3adbc85d0a5fb30a8cf0f018a8
effectively removed that cache, while still making things
faster though.
This CL puts back the caching on the StackFrameInfo objects
by reusing the `offset` slot to store the computed source
position (as indicated by a bit in the `flags`). For promise
combinator async frames, the bit is always set and the
`offset_or_source_position` slot thus always contains the source
position (aka the `promise index` in this case). We also
added a `StackFrameInfo::ComputeLocation()` method to remove the
last remaining place where we'd peek into the StackFrameInfo from
outside stack-frame-info.{cc,h}.
Also-By: kimanh@chromium.org
Bug: chromium:1077657, v8:8742, chromium:1069425
Change-Id: I59e26a91965617163776e6cc2610b88e6925452c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695386
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72752}
This is a reland of 5cc7bfd04c, after the
dependency has relanded.
Original change's description:
> [compiler] Clean up ObjectDataKind
>
> In particular: remove PossiblyBackgroundSerializedHeapObject in favor of
> either SerializedHeapObject or BackgroundSerializedHeapObject, depending
> on the (existing) argument to the ObjectRef constructor.
>
> Bug: v8:7790
> Change-Id: I0a67872c377107799233742cc7774bea62811d0f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2681946
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72591}
Tbr: solanes@chromium.org, nicohartmann@chromium.org
Bug: v8:7790
Change-Id: I7de88f54172078a42b5aa341b11309ac3581eed0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695589
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72751}
This removes a redundant SpillRegisters implementation in
liftoff-assembler-ia32.h, and uses the existing platform-independent
method in liftoff-assembler.h consistently.
R=ahaas@chromium.org
Bug: v8:11384
Change-Id: I20f0417c248e06557dc1fe8bab834a99257940de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695399
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72750}
Port 15f3392a7e
Original Commit Message:
This CL adds support for instrumentation breakpoints in wasm. The
request for "break on entry" is set on the script, and we need to
keep
it stored there because there might not be any instances of that
wasm
module yet. Once instances get created, the flag value is
transferred to
all instances. The flag stored there is then checked in the function
prologue in Liftoff debugging code. This ensures that we will stop
at
the first valid break position in any function within that module.
Hitting that instrumentation breakpoint will then clear the flag
from
the script and from all other live instances (in the same isolate).
A first basic test is contained in this CL. More tests will be added
later.
R=clemensb@chromium.org, midawson@redhat.com, mfarazma@redhat.com
BUG=
LOG=N
Change-Id: I892eec22aa804abb8b22f3bdd811664f9a2605d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695606
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/master@{#72749}
This reverts commit 1370b29e75.
Reason for revert: Breaks some targets that lack a dependency onto v8-gn.h, see https://crbug.com/1178409.
Original change's description:
> [build] Enable external flag header with defines
>
> Due to some unusual build failures on some trybots,
> v8_generate_external_defines_header was reverted to false. This turns it
> back on but changes the behaviour so that defines are added to the
> command line as well as to the header. Because the generated header
> checks that flags that should be unset are actually unset and flags that
> should be set are either unset or set to 1, this will cause build
> failures on many types of mismatches, although it will not detect where a
> flag is not set on the command line when it is set by the header.
>
> If no further failures show up with this, the hybrid part can be removed
> and the v8-gn.h header can stand on its own.
>
> Bug: v8:11292, v8:11341
> Change-Id: I1deeeebec58f79607e68a28f808649e884810923
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649041
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72327}
TBR=mlippautz@chromium.org,delphick@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:11292
Bug: v8:11341
Change-Id: I6cf57014ef8be73c286ad9c5ebf597915f183717
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695400
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72748}
We could revisit this later, but right now the direction we're going is
simply keeping fast paths in the called builtins and not generating more
custom inline code.
Bug: v8:11429
Change-Id: I2e3a67e1a2a2ab62e8c785dd9bdf2de3e7215f60
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695405
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72747}
Add (ToNumber|ToNumeric)_Baseline builtins which get the feedback vector
and context from the stack, perform ToNumber/ToNumeric, and update
feedback. These share C++ code with Builtins::kToNumber, but don't call
it directly, as they need to collect feedback as part of the conversion.
Bug: v8:11420, v8:11429
Change-Id: Idca1281004ec27096cbe9204653fdd72386ab52b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692573
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72746}
The check was a leftover from a debugging session.
We don't have a feedback vector even though we have baseline code,
e.g. when we share baseline code across realms. In this case
the feedback vector will be allocated upon the first invocation
of the function.
Bug: chromium:1177217
Change-Id: Ia5cde35b0f5d746c2ba64d3ca2083acdfaf286bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695396
Auto-Submit: Patrick Thier <pthier@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72745}
Add a new StackFrame class for unoptimized frames (which are either
interpreted or baseline). BaselineFrame becomes a subclass of this
rather than InterpretedFrame, and the various frame constants helpers
are similarly amended.
Bug: v8:11420, v8:11429
Change-Id: I87e9368aef48ef06a39476bf826f379ce1441528
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692208
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72743}
This adds a call to re-compile top level functions in case
no shared function info could be found. We ran into a bug
where it was not possible to set a breakpoint on the
top-level function since it was already removed by the GC.
Bug: chromium:1137141
Change-Id: I5bb6984825eee8ebcb44619e15b3acf3d118b9bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2672181
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72738}
- Add missing EnsureStackSpace before unpacking the exception (decoder)
- Pop current catch when delegating to the caller (graph builder)
- Mark throw opcode as unconditional jump
R=clemensb@chromium.org
Bug: v8:8091, v8:11449
Change-Id: I702f6a99581476e77d254e2ea91f9c463ceed444
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692688
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72737}
Also block sending "type" as part of the ObjectPreview, but only send
the "value" property. The front-end will be updated to display
WasmValueObject's similar to what we do for wrapper objects (i.e.
StringWrapper and the like). The matching front-end change is still
pending.
Also refactor the WasmValueObject to have dedicated constructors for
the individual types (i32, i64, f32, f64, externref and v128). This
way we can just reuse the existing logic in descriptionForObject()
and we also don't need to store the "type" on the object itself (not
really performance sensitive, but fewer moving parts / things that
can go wrong).
This also addresses the crash in https://crbug.com/1166077#c16 since
the WasmValueObject instances now have a proper JSFunction in their
maps' constructor_or_backpointer slot and are thus able to locate
their creation context. Note that this doesn't generally address
https://crbug.com/1166077 itself, but only the WasmValueObject case.
Screenshot: https://imgur.com/kbd3bix.png
Bug: chromium:1170282, chromium:1071432
Bug: chromium:1159402, chromium:1166077
Change-Id: Iae649cad155efd774cfb1f4eea8cf406e413c03a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692574
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72736}
Instead of looking up the register holding the instance parameter, and
checking that this is the constant we expected, do it the other way
around: Use the constant, and check that this matches the information in
the CallDescriptor. This saves a few instructions on every Liftoff
function compilation.
Drive-by: Move comments, checks, and code emission closer together.
R=thibaudm@chromium.org
Bug: v8:11384
Change-Id: If51425479ded4f271de231479c21e24acefe7f35
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692575
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72735}
This CL is part of a series that adds the C++ implementation of
SwissNameDictionary, a deterministic property backing store based on
Swiss Tables.
This CL adds swiss-hash-table-helpers.h, which contains helpers
that are mostly independent from a particular swiss table
implementation (like SwissNameDIctionary) and can therefore be re-used
by potential other Swiss Table implementations in the future. As a
consequence of that, those helpers are largely taken unchanged from
Abseil.
Bug: v8:11388
Change-Id: I27636731c2166cb10240b847a1d7df0412aa0a33
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2687752
Commit-Queue: Frank Emrich <emrich@google.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72734}
- Baseline is to be consider non-optimized code, so for consistency we rename these functions to DiscardBaselineCode.
- Move to debug/, since discarding baseline code is only used by the debugger.
- %DeoptimizeNow and %DeoptimizeFunction are not to be used to tier down from Sparkplug to Ignition
Change-Id: I050607d4d6978907c589e54c57e940979b0a9a15
Bug: v8:11429
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692699
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72732}
This reverts commit 6beed8d544.
Reason for revert: Breaks some targets that lack a dependency onto v8-gn.h, see https://crbug.com/1178409.
Original change's description:
> [build] Remove V8_GN_HEADER hybrid mode
>
> v8_generate_external_defines_header has been enabled for a couple of
> weeks now with no problems, so this removes the hybrid state where
> V8_GN_HEADER was defined on the command line along with the other
> defines.
>
> Bug: v8:11292, v8:11341
> Change-Id: Ie78f00afe5d1cbca751101a7beb61a18c7d86d04
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2681947
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Auto-Submit: Dan Elphick <delphick@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72597}
TBR=mlippautz@chromium.org,delphick@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
No-try: true
Bug: v8:11292
Bug: v8:11341
Bug: chromium:1178409
Change-Id: Ic730ae1bdfe09b13cc0bec96a092822b1874fb0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692702
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72731}
This flag name caused misunderstanding in CLs, so it's better to
rename it. With the new name it's clear that this flag is talking about
the outgoing parameters and not about the incoming parameters.
R=jgruber@chromium.org
Bug: v8:11384
Change-Id: Ib371ce4e1eae9a20e61ac2cda67dff48a120144f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690596
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72728}
Rolling v8/build: d1fa78c..f306685
Rolling v8/buildtools: 7e85fef..228b1c1
Rolling v8/buildtools/linux64: git_revision:55ad154c961d8326315b1c8147f4e504cd95e9e6..git_revision:dfcbc6fed0a8352696f92d67ccad54048ad182b3
Rolling v8/third_party/aemu-linux-x64: zN4Wm-IY1Nd2ZF2IFXt3kLaxI1cDiwANew4sQzpVRSgC..FC12QGMdCPb7lf3NBC6KhslYMLXQvJuO0VQnTiEAKxAC
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/d2aa569..e4328db
Rolling v8/third_party/depot_tools: 398091b..7386a1e
Rolling v8/tools/clang: 35e7868..fea4246TBR=v8-waterfall-sheriff@grotations.appspotmail.com
Change-Id: Id8600af539ce4eb95cc8da5da2ba39048c789d1f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2694108
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#72725}
Same code sequence as x64.
Bug: v8:11416
Change-Id: Ibbd4cbf75e10b0ce876d42809d909868fdb86b87
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2686309
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72724}
HeapObjectHeader::GetSize returns object size including
HeapObjectHeader. This is find for our internal usages since we want to
know the actual size consumed by the object.
ObjectSizeTrait should report object size for external users for which
the HeapObjectHeader should be invisible. The sizes returned by the
trait should exclude the header.
Bug: chromium:1056170
Change-Id: I75111b9a3d0d27d0a39df4abdacaa84f1cee3a5a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692689
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72723}
Previously it was possible for a slot operand to be allocated a
constant operand which is not valid. This CL adds support to the
mid-tier register allocator to keep track of whether spilled operands
can support constant operands, and if not to instead move the constant
to a spill slot at it's definition point, and use that spill slot
instead.
In the process of doing this, we can cleanup the hack that
required constants to always be allocated to a register for
REGISTER_OR_SLOT operator policies.
BUG=chromium:10772,v8:10772,v8:9684
Change-Id: I975ea2c481b45fc0855e175bc6dc2bd0a83f509a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692569
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72722}
This is a reland of a16add806d.
The fixes are adding disassembly for pcmpgtq and vpcmpgtq.
While fixing also noticed a mistake in assembler for pcmpgtq,
which flipped dst and src.
Also realized that we don't detect SSE4.2, so adding that in.
PS2 contains these changes.
Original change's description:
> [wasm-simd][ia32] Implement i64x2 signed compares
>
> The code sequence is exactly the same as x64.
>
> Bug: v8:11415
> Change-Id: I53ed2723eda29c0a250cff514372a3d45b203476
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683495
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72637}
Bug: v8:11415
Change-Id: If6a18af2d7de20ac8ad38f94b6d0220769397194
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688119
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72721}
If we return to code after a dynamic map check bailout, ensure the
return point is after the branch poisoning logic, since we might
cause the speculation poisoning register to be cleared otherwise.
Change-Id: Ia003aac16196857218fdfcdc7c2a4c9e8f02b1c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692576
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72719}
Port 94b294b349
Original Commit Message:
Before the removal of the arguments adaptor frame, we could set {actual arguments count} = {formal parameter count} before restarting a live frame to avoid re-entering in the adaptor frame trampoline.
This does not work anymore, since we now need the correct value of the {actual argument count} to be pushed in the callee frame to be used in its epilogue.
This CL calls InvokeCall with the correct argument count and the kDontAdaptArgumentsSentinel to skip arguments adaptation.
R=victorgomes@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: Idc7f712d1860192dc0306366ca77230ed8ad3455
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2693046
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#72716}
As outlined in the design document linked below, we're removing the
support for the non-standard Function.displayName property for the
purpose of Error.stack and DevTools Inspector stack traces. The
motivation here is that the negative lookup is costly, and we have
Function.name as a standard alternative (configurable since ES6 for
exactly this reason).
I dediced to go with JSFunction::GetDebugName(), since
JSFunction::GetName() was confusing in that it'd only get the "name"
property's value if it's a data property, but not with accessors.
JSFunction::GetDebugName() makes it clear that this is really a debug
helper function and might not give you the "name" property value.
Doc: https://bit.ly/devtools-function-displayName-removal
Bug: v8:8742, chromium:1177685, chromium:1077657, chromium:17356
Change-Id: I7717585cbace626174b2f2ed2a4f68f75429eca1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692189
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72715}
Ephemerons are based around WeakMember which may just be null at the
time the pair is considered for liveness. Bail out of marking for null
keys, as they write barrier would anyways make the value strong when
marking the key.
Bug: chromium:1056170
Change-Id: If8775a370824b88fc67fa479a0c0893985fbf5f4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692571
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72714}
If the exception tag does not match any of the catch blocks and there is
no catch_all block, it should be rethrown.
R=clemensb@chromium.org
Bug: v8:8091
Change-Id: I8df80f51340fc6265f5ef4308ee3b0f892ee3a90
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690599
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72713}
