When V8 throws an uncaught exception, we store a JSMessageObject
with a stack trace and source positions on the isolate itself.
The JSMessageObject can be retrieved by a TryCatch scope
and is used by the inspector to provide additional information to the DevTools
frontend (besides the exception).
Introducing top-level await for REPL mode causes all thrown exceptions
to be turned into a rejected promise. The implicit catch block that does this
conversion clears the JSMessageObject from the isolate as to not leak memory.
This CL preserves the JSMessageObject when the debugger is active and stores
the JSMessageObject on the rejected promise itself. The inspector is changed
to retrieve the JSMessageObject in the existing catch handler and pass the
information along to the frontend.
Drive-by: This CL removes a inspector test that made assumptions when a promise
is cleaned up by the GC. These assumptions no longer hold since we hold on to
the promise longer.
Bug: chromium:1021921
Change-Id: Id0380e2cf3bd79aca05191bc4f3c616f6ced8db7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967375
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65497}
Allocate memory more quickly so the test completes faster. (On the ARM
simulator tests with slow asserts and verify-heap, it was taking around
20 minutes).
Change-Id: I6b4d0a4788817c4f996a073cc3fdf8b69d11bc40
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1973731
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65495}
This change implements support for reading and writing bitfields from
Torque code, and adds a couple of unit tests for this functionality. As
Tobias suggested, the LocationReference for a bitfield access contains
a nested LocationReference to where the bitfield struct is stored, so
that store operations can read the original value, update part of it,
and write it back.
Bug: v8:7793
Change-Id: I1004a5c7fcb6cf58df5ad50109b114bf89c80efc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1957841
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65487}
Add a --max-serializer-nesting flag which defaults to 25.
Fixed: chromium:1034768
Change-Id: Ib68f26ce4bf53db297b25d16a046d275beaec642
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969895
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65486}
For out-of-line code, we need to generate the debug side table
information at the point where the out-of-line code is being triggered,
not when it is emitted (at the end of the function).
This CL also adds more tests to check the actual content of the debug
side table in different scenarios.
R=jkummerow@chromium.org
Bug: v8:10019
Change-Id: I7714c86ee7edc4918b5ecc97cbded84c27b00e09
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967388
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65481}
This adds heuristics to perform young and full GCs on allocation
of external ArrayBuffer backing stores.
Young GCs are performed proactively based on the external backing
store bytes for the young generation. Full GCs are performed only
if the allocation fails. Subsequent CLs will add heuristics to
start incremental full GCs based on the external backing store bytes.
This will allow us to remove AdjustAmountOfExternalMemory for
ArrayBuffers.
Bug: v8:9701, chromium:1008938
Change-Id: I0e8688f582989518926c38260b5cf14e2ca93f84
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803614
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65480}
If --perf-prof is specified, we commit the whole code range at once, and
never update the {total_committed_code_space_} counter (see
{WasmCodeManager::Commit} and {WasmCodeManager::Decommit}). Hence we
should also not decrement that counter when the native module dies.
R=jkummerow@chromium.org
Bug: chromium:1032753
Change-Id: I9a40f1a1322485d7142ed56f5c9365305aa0e056
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969790
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65476}
Since RecordStats during GC, (when it fails to recover enough memory),
it unsafe for it to allocate any memory. Thus it cannot call PrintStack
which can call SharedFunctionInfo::EnsureSourcePositionsAvailable and
which may allocate, so this removes the call to PrintStack which is
apparently not useful for debugging anyway.
Bug: chromium:1032087
Change-Id: I94feeaab1445f7fd4f770a20197546fc40c77390
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967377
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65475}
Objects in arrays take the shape of the object right before as feedback to
speed up object creation. If a subsequent object with the same shape has a
member that also has the same shape, that member can cause the feedback map to
be deprecated. To avoid confusion, we now update (dedeprecate) the feedback map
before use.
Thanks a bunch Seth Brenith for figuring out the issue!
Bug: chromium:1029077
Change-Id: I047b1acfd4906616a2302f253ab9cd29272bdc79
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1970211
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65474}
In this test we expect that the feedback vector is not flushed
so we retain what we have learnt from the earlier executions. If we
flush the earlier feedback the code might deoptimize again and the test
fails. Hence adding --no-stress-flush-bytecode and --no-flush-bytecode
flags.
Bug: v8:10035
Change-Id: Ia71748e83d64a731f595fed7f5b85a8dafa2b31a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969850
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65472}
MapRef::GetStrongValue now returns an Optional to account for the case
where we can't figure out the name of the bound function during
serialization. We could reach out to the heap in the future in this
case.
Fixed: chromium:1034203
Change-Id: I9fa81921b5dbd8bc9f68aa3c10921bc01b695a6b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967386
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65470}
Add an API on Isolate that returns a sorted vector of code pages allocated
within V8. The implementation is designed to be signal-safe, so that the
user (the UMA sampling profiler) can access this information from a signal
handler, where allocation and taking locks is prohibited.
This CL adds the machinery for maintaining the list of allocated code
pages. Further CLs will modify the Unwinder API itself to accept the code
pages provided by this API.
The unwinder API currently uses the reserved virtual-memory range called
the CodeRange to identify where all V8 code objects live, but this doesn't
exist on arm32 or any 32-bit platform, so this approach adds a way to
expose the location of all valid V8 code objects in a signal-safe way for
use by the UMA sampling profiler.
On 64-bit, this API always gives the code_range and embedded_code_range, and
does not maintain a vector of code pages. This is so that we have a unified
API on 32 and 64-bit that can be used in exactly the same way by embedders.
Design doc:
https://docs.google.com/document/d/1VGwUult5AHLRk658VetwEHMOmDDxA2eDQs9lDFMZTE0
Bug: v8:8116
Change-Id: I732509a45121fc54853182481c24d1083275afce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564068
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65469}
The {cmp} instruction might add an entry to the constant pool at a time
where we didn't expect any entries to be added.
This can be fixed by moving the {CheckConstPool} call *after* the {cmp}.
R=mslekova@chromium.org
Bug: chromium:1034394
Change-Id: If075ad0b02e2973a734d70d9e58c205bd14e6a33
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967380
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65463}
This makes it obvious that methods are actually macros.
Also, in the future, we might allow methods that are actually builtins.
Bug: v8:7793
Change-Id: Ib641c4b5a222b27c67aa0c31fd3611ed4a11842c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967330
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65455}
This improves documentation about some things that came up
in conversation and things that I noticed while working on
those other things. :)
Change-Id: I4f47cec6594f7b331259bea8ed506f5de908d438
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1954386
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65449}
Bug: chromium:1029530
Change-Id: I12aa4c238387f6a47bf149fd1a136ea83c385f4b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962278
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65434}
Part of the GetObjectProperties test case is for verifying the human-
readable brief object description string that GetObjectProperties
returns. That string might look something like this:
"xy" (0x28f038d5 <v8::internal::SeqOneByteString>)
GetObjectProperties also tries to detect known immortal objects by
recognizing their addresses, which is useful in crash dumps with limited
memory. The recognized object name, if it exists, is prepended to the
description string. In order to provide this data accurately (in builds
without pointer compression), GetObjectProperties relies on the caller
to provide the addresses of the first pages in read-only space, map
space, and old space. If the caller doesn't provide those addresses,
then GetObjectProperties does the best it can with limited information
and reports possible matches based on an object's offset within the heap
page that contains it. So the result string might look like this, if the
object happened to get allocated at a lucky offset within its page:
maybe LoadHandler3Map "xy" (0x28f038d5 <v8::internal::SeqOneByteString>)
As a result, when testing these descriptions, we should generally check
that they contain the interesting data rather than that they start with
it, because some incorrect "maybe" match with a known object might be
included at the beginning.
Bug: v8:10034
Change-Id: I0cf5afd67793a239614aba3665ef57cd2d663a47
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1950233
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#65432}
With bytecode flushing and the current OSR triggering mechanism which
stores OSR nesting level on bytecode array it is possible to trigger
OSR on a closure that doesn't have feedback vector.
Bug: chromium:1031479
Change-Id: I4c62486f6b0eb6d6f9c96f98c1c1b275f3e6d6d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962850
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65431}
This unifies marking worklists handling by the main thread marker and
by the concurrent markers. A new class called MarkingWorklistsHolder
owns all marking worklists: the default worklist, the on-hold worklist,
and the embedder worklist. Each thread creates a local view of the
marking worklists by creating an instance of MarkingWorklists.
Additionally, marking visitors now work on MarkingWorklists instead of
accessing each worklist individually.
Besides cleaning the code up, this CL provides a bottleneck for
implementing per-context worklists.
Bug: chromium:973627
Change-Id: I52ad65c94bc0695287ba7bf4d8a814a9035e2888
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1941947
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65421}
This reverts commit 3b7535636f.
Reason for revert: breaks in multiple places:
https://bugs.chromium.org/p/chromium/issues/detail?id=1029368https://bugs.chromium.org/p/chromium/issues/detail?id=1029361
Original change's description:
> Reland "[runtime] Cache prototype chain enumerable keys in PrototypeInfo"
>
> This is a reland of 5253d7bf15
>
> Original change's description:
> > [runtime] Cache prototype chain enumerable keys in PrototypeInfo
> >
> > This CL adds a prototype_chain_enum_cache to cache the enumeration of a
> > prototype and its entire chain on the PrototypeInfo. It can improve for-in
> > performance via simply merging the receiver enumeration with this cache.
> >
> > It improves the score of JetStream2-tagcloud-SP case by ~9% on IA Chromebook.
> >
> > Contributed by tao.pan@intel.com
> >
> > Change-Id: Ib40bfe41e772672337155584672f06fa1ba1e70d
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1870844
> > Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#65224}
>
> Change-Id: I93b74727c46abbaab163324c50fbd977fcc9bb36
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1955232
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
> Cr-Commit-Position: refs/heads/master@{#65377}
TBR=verwaest@chromium.org,shiyu.zhang@intel.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I5b0d544e802ffda6a6804931087f37cb112805ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962273
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65418}
This CL generalizes and improves how we handle allocations in Torque.
Overview of the changes:
- Remove obsolete special handling for JSObject classes, since it was
incomplete: It breaks as soon as slack tracking is active.
- Handle array initialization using slices.
- Properly align allocation sizes. This enabled allocating strings.
- Port AllocateSeq{One,Two}ByteString to Torque, which is much easier
now than the old CSA code since allocation size alignment and
large-object space allocation just happen out-of-the-box.
- Remove obsolete or unnecessary intrinsics, some of them turn into
macros in the torque_internal namespace.
- Distinguish between header size and overall size for ClassType,
make size optional and only defined when it is statically known.
Bug: v8:10004 v8:7793
Change-Id: I623db233e7fb4deed54e8039ae0c24705e9a44e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1932356
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65397}
We use the compilation entry point as a caching scope for deserializing
lookups, to avoid redundantly iterating over parent scopes when
accessing the same variable multiple times.
However, this caching scope messes with lookups that are looking for
lexical name conflicts, as opposed to just resolving variables. In
particular, it messes with name conflict lookups and sloppy block
function hoisting checks, when there are other scopes in the way, e.g.
function f() {
let x;
try {
throw 0;
}
catch (x) {
// This catch is the entry scope
// Naive use of caches will find the catch-bound x (which is
// a VAR), and declare 'no conflict'.
eval("var x;");
// Naive use of caches will find the catch-bound x (which is
// a VAR), and determine that this function can be hoisted.
eval("{ function x() {} }");
}
}
Previously, we worked around this by avoiding cache uses for these
lookups, but this had the issue of instead caching the same variable
multiple times, on different scopes. In particular, we saw:
function f() {
with ({}) {
// This with is the entry scope, any other scope would do
// though.
// The conflict check on `var f` caches the function name
// variable on the function scope, the subsequent 'real'
// lookup of `f` caches the function name variable on the
// entry i.e. with scope.
eval("var f; f;");
}
}
With this patch, we change the caching behaviour to cache on the first
non-eval declaration scope above the eval -- in the above examples, this
becomes the parent function "f". For compilations with no intermediate
non-decl scopes (no with or catch scopes between the function and eval)
this becomes equivalent to the existing entry-point-based caching.
This means that normal lookups do have to (sometimes) iterate more scopes,
and we do have to be careful when using the cache to not use it for
lookups in these intermediate scopes (a new IsOuterScope DCHECK guards
against this), but we can now safely ignore the cache scope when doing
the name-collision lookups, as they only iterate up to the outer
non-eval declaration scope anyway.
Bug: chromium:1026603
Bug: chromium:1029461
Change-Id: I9e7a96ce4b8adbc7ed47a49fba6fba58b526235b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1955731
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65391}
This reverts commit 026a0c214a.
Reason for revert: Reverting due to https://crbug.com/1029461
Original change's description:
> [parser] Fix variable caching for conflict lookup
>
> During conflict lookup (for lexical variables and sloppy block function
> hoisting), we cache the looked-up variable on the current scope if the
> lookup goes through a ScopeInfo. However, for variable lookup during
> scope analysis, we use the "entry point" as the cache.
>
> Since both lookups can create Variables, this can cause us to create
> duplicate variables, e.g. a duplicate function name variable in the
> attached test.
>
> Instead, for ScopeInfo conflict lookups we can cache the result on the
> function's outer scope, which shoud be equivalent to the entry point.
>
> As a (necessary) drive-by, we can terminate the lookup early if we find
> a VAR with the same name, as we can safely assume that its existence
> means that it doesn't conflict, which means that our variable can't
> conflict either.
>
> Bug: chromium:1026603
> Change-Id: I19f80f65597ba6573ebe0b48aa5698f55e5c3ea1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928861
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65138}
TBR=leszeks@chromium.org,verwaest@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1026603
Bug: chromium:1029461
Change-Id: Id7f5dd342e32e1bb57c51b3748feff32ee0ba41d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1958014
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65390}
Before this CL a byte was used per bucket to store whether the bucket
is possibly empty or not. This CL changes this such that each bucket
only needs a single bit.
PossiblyEmptyBuckets is now a word in the page header. If more bits
are needed than fit into a single word, an external bitmap is
allocated using AlignedAlloc. Storing this on the page header, allows
to remove initial_buckets from the SlotSet. The SlotSet allocation is
then again a power-of-2 in release mode.
Reland of https://crrev.com/c/1906376: Incorrect DCHECK was removed.
WordsForBuckets was simplified and a test was added for it.
Bug: chromium:1023139
Change-Id: I9a08e03a9c10e5781a146b9a28dab38824aad91f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1954391
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65385}
This removes the --experimental-wasm-sat-f2i-conversions flag. This
feature is shipped since v7.5.
R=ahaas@chromium.org
Change-Id: I354d9528be40caac77cd4e41adcd39d013448339
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1958009
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65384}
This CL is a prepatory step towards moving the stack locals blacklist
from the DebugEvaluateContext to the respective {ScopeInfo} objects.
The locals blacklist is used during local debug evaluate to
decide whether a context lookup can advance the context chain
upwards, or if lookup needs to stop at the current scope.
This CL also introduces a "Recreate" static helper method, that
allows an existing ScopeInfo to be cloned, but with a locals
blacklist attached. This will be needed since blacklists are only
created on-demand during debugging.
R=leszeks@chromium.org
Bug: chromium:1027475, v8:9938
Change-Id: I673dbc99ce9fdc84cb5cda3f9710ba2b76ab92ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1946349
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65380}
This is a reland of 5253d7bf15
Original change's description:
> [runtime] Cache prototype chain enumerable keys in PrototypeInfo
>
> This CL adds a prototype_chain_enum_cache to cache the enumeration of a
> prototype and its entire chain on the PrototypeInfo. It can improve for-in
> performance via simply merging the receiver enumeration with this cache.
>
> It improves the score of JetStream2-tagcloud-SP case by ~9% on IA Chromebook.
>
> Contributed by tao.pan@intel.com
>
> Change-Id: Ib40bfe41e772672337155584672f06fa1ba1e70d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1870844
> Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65224}
Change-Id: I93b74727c46abbaab163324c50fbd977fcc9bb36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1955232
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
Cr-Commit-Position: refs/heads/master@{#65377}
This adds a method to generate the debug side table via Liftoff, and
adds first tests that check that the number of entries is as expected.
These tests will be extended in a follow-up CL to test the actual
content of the debug side table.
R=mstarzinger@chromium.org
Bug: v8:10019
Change-Id: I393ffabed3408463ffba232a66e2dffd7dd74f15
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1954390
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65370}
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}
In 5742da056a, the toString property was
accidentally applied to all NativeError prototypes, when it should only
be inherited from Error.prototype.
Refs: https://github.com/tc39/ecma262/issues/1794
Bug: v8:10017
Change-Id: I2af9a31f463deb9871dd7a4a5a2e4dd7485ed38c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1933054
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65355}
The current error message assumes all classes are named, which results
in a double space and awkward wording when calling an anonymous class
constructor.
Bug: v8:10025
Change-Id: Ibe913152c0816cbbaaa0c7a88db4e415762ae9bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1947336
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65354}
Bug: v8:9970
Change-Id: I0e542fc63211e78800eab82257ccab9583305433
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1946534
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65351}
This CL attempts to run unittests on Fuchsia
using Infra
Bug: chromium:934932
Change-Id: I4b7cb740e17e65e91ca8c6ba6dfd07719e473e20
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1948709
Commit-Queue: Almothana Athamneh <almuthanna@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65349}
Currently a TracedNode of a TracedReference is freed only if its target
V8 object is unreachable. This is problematic for TracedNodes created for
long-living (or immortal) V8 objects and leads to memory leaks.
This CL adds logic for collecting unreachable TracedNodes:
1) Each TracedNode gets a markbit. Initially the markbit is set (i.e.
we have black allocation for TracedNodes).
2) During marking RegisterEmbedderReference sets the markbit of the
corresonding TracedNode.
3) In the atomic pause of Mark-Compact when TracedNodes are iterated,
we check the markbits and free TracedNodes with cleared markbits.
After this processing all markbits are cleared for the next GC.
Note that the new logic does not apply to TracedNode that have
callbacks and/or destructors.
Bug: chromium:1029738
Change-Id: I38e76a8b4a84170793998988b1a7962e40874428
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1948722
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65347}
Also make return and unconditional jumps kill the environment instead
of clearing it. This was still leftover from before we introduced
liveness and prevented sharing as well.
Bug: v8:7790
Change-Id: Ic79d64c9eaedf608d26e3265d4b27d21f7f3dfe1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1948710
Auto-Submit: Georg Neis <neis@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65345}
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}
