This reverts commit 0d6aa842e6.
Reason for revert: Suspected to be triggering many test flakes - https://crbug.com/1005723
Original change's description:
> [Heap] Allocate descriptor array in young
>
> This hopefully fix the regression test from c693e005a7
>
> Bug: v8:1004766
> Change-Id: If3c554070af6b795e4b3f99cd592a62453028874
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809363
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Victor Gomes <victorgomes@google.com>
> Cr-Commit-Position: refs/heads/master@{#63858}
TBR=ulan@chromium.org,victorgomes@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1004766, chromium:1005723
Change-Id: I763036ea6873b4b95783981e9e9f4e79782e7a4b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1816515
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63915}
Add a new test SimdLoadStoreLoadMemargOffset to test this, without this fix
this test would have failed.
Bug: v8:9753
Change-Id: I119adda8e3c6c7adb0ad4023298bbce9c0c64a01
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1811457
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63914}
This cl adds support for top level await to d8, but still
does not allow top level await through parsing.
Unfortunately, due to that restriction this cl has no automated
tests, but I added a 'top-level-await' variant and manually
confirmed it passes locally.
Bug: v8:9344
Change-Id: I3528442768107f5ad1ed1e9e947cfceae91c0cc6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1808483
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63909}
If we can read an object's Map pointer but not any data from the Map
itself, we may still be able to accurately describe the object's type if
the Map pointer matches one of the known Maps from the snapshot.
GetObjectProperties uses that data in one of two ways:
- If it is sure that the Map pointer matches a known Map, then it uses
the type from that Map and continues as if it read the type normally.
- If the Map pointer is at the right offset within a heap page to match
a known Map, but the caller didn't provide the addresses of the first
pages in Map space or read-only space, then the type of that Map is
just a guess and gets returned in a separate array. This gives the
caller the opportunity to present guessed types to the user, and
perhaps call again using the guessed type as the type hint.
Bug: v8:9376
Change-Id: I187f67b77e76699863a14534a9d635b79f654124
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787986
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63908}
This reverts commit d7b67ce206.
Reason for revert: broke tsan https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8901789268326050304/+/steps/Check/0/logs/enumeration-order/0
Original change's description:
> [Context] Add a bit flag to indicate if extension might exist
>
> Checking the bit flag instead of comparing pointers should improve performance.
> This will also allow us to remove the extension slot in Context and save memory.
>
> Bug: v8:9744
> Change-Id: I7ab9feeadfb934955798d877d13bc0e1d78a191c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1814918
> Commit-Queue: Victor Gomes <victorgomes@google.com>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63906}
TBR=ulan@chromium.org,leszeks@chromium.org,victorgomes@google.com
Change-Id: I3d2261e24c9c7da5f5a1d49803361bc6f0770330
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9744
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1816514
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63907}
Checking the bit flag instead of comparing pointers should improve performance.
This will also allow us to remove the extension slot in Context and save memory.
Bug: v8:9744
Change-Id: I7ab9feeadfb934955798d877d13bc0e1d78a191c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1814918
Commit-Queue: Victor Gomes <victorgomes@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63906}
This CL enables regexp interpreter and tier-up to the compiler after one
execution by setting the --regexp-tier-up flag to true by default. The
number of times a regexp is interpreted before tiering-up is controlled
by the --regexp-tier-up-ticks flag which is already set to 1 by default.
Change-Id: I79ff7fcd159f50f2f5351b339d8ffb21af039a86
Bug: v8:9566
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1816501
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Ana Pesko <anapesko@google.com>
Cr-Commit-Position: refs/heads/master@{#63905}
The predictable platform can make tasks deadlock if the spawning task
is holding a lock that the spawn task also wants to take. This is
because the spawned task is just executed immediately within the
"context" of the spawning task.
The wasm async compile tests deadlock because the
{BackgroundCompileTask}s hold the shared {BackgroundCompileToken}
(reader lock) while spawning new tasks via {OnBackgroundTaskStopped} ->
{RestartBackgroundTasks}. The new tasks might want to cancel
compilation via {BackgroundCompileToken::Cancel}, which takes the
writer lock and hence deadlocks.
This can not happen on any other platform, since tasks are not nested
that way.
R=ahaas@chromium.org
Bug: v8:9760
No-Try: true
Change-Id: I9fc34d5de386aa5c6fdd64a1570fddcff872ec95
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1816502
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63904}
With --wasm-far-jump-table, it will be possible to create 10k (and
more) modules in one process. So far, we hit the virtual address space
limit around 1k modules, because each module makes a reservation of
{kMaxWasmCodeMemory} upfront. After this change, each module will only
reserve the estimated needed code size (if --wasm-far-jump-table is
set).
The test is carefully optimized to not execute too much code in the
loop, so it can still run in simulators in reasonable time. Note that
the time for actually compiling the module is spent in C++, which is
fast in simulator builds.
R=mstarzinger@chromium.org
Bug: v8:9477, v8:9651
Change-Id: If74a825d272a65b82ca5433cb648b6a2271872e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1811038
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63903}
The CPURegister class has an additional "type" field to represent an invalid
register while the cross-platform RegisterBase class uses -1 as a register code.
For consistency and to avoid potential bugs from confusing x0 and
`CPURegister::no_reg()`, use -1 as a register code as well in CPURegister.
Change-Id: I1a36230091433bc854a5966f36e3c25e33a406c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813746
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#63902}
This makes it possible to plumb string representation of stack trace id
across various channels, e.g. for network requests.
Drive-by: extracted class V8DebuggerId, which encapsulates operations
with pair<int64_t, int64_t>.
Bug: chromium:988842
Change-Id: I348c91390a85bf07c746d1b1c4a7775f44c7d769
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725193
Commit-Queue: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63900}
This is a reland of 6f9b2bd48a
We must load JSTypedArray::base_pointer in TurboFan as tagged value otherwise
this value may become stale pointer after GC.
Original change's description:
> [ptr-compr] Make on-heap JSTypedArrays smi-corrupting friendly
>
> On-heap typed arrays contain HeapObject value in |base_pointer| field
> and an offset in |external_pointer| field. When pointer compression is
> enabled we want to combine decompression with the offset addition.
> In order to do that we add an isolate root to the external_pointer value
> and therefore the data pointer computation can is a simple addition of
> a (potentially sign-extended) |base_pointer| loaded as Tagged_t value
> and an |external_pointer| value.
>
> Bug: v8:9706
> Change-Id: Id5c546c353c81fb25e3598921bc78165d10a9c44
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807369
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63874}
Bug: v8:9706, chromium:1005599
Cq-Include-Trybots: luci.chromium.try:gpu-fyi-try-win10-nvidia-rel-64
Change-Id: I7bbd2a439306cdd11f2bb0dab5863498624d9740
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813744
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63898}
- Check validity of node id in Node constructor.
- Turn overflow check in NextNodeId() into debug check only, since that
is not checking the interesting overflow anyway.
- Increase width of Use::InlineCountField to use all available bits.
Bug: chromium:1003286
Change-Id: I59af68e29a466e151f7048e1f15bd56d3fa58e5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813019
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63897}
The {code_table_} only contains entries for the declared functions, and
is indexed by a slot index. The {PatchJumpTableLocked} and
{PatchJumpTablesLocked} functions on the other hand expected a function
index (offset by the number of imported functions). From that it
computes the slot index again.
This translation was missing in one place. This CL fixes this by
directly passing the slot index instead of the function index to these
methods. In all locations, we computed the slot index anyway for
addressing the code table.
Drive-by: Use more unique_ptr for managing the {code_table_}. This
avoids ever having to store raw pointers.
R=ahaas@chromium.org
Bug: v8:9477
Change-Id: I81caa53b74da010aee5854879e98e82b7773098b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813742
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63896}
Allocation observers used to set allocation limits with the intention
to statistically sample allocations that crossed those points. Those
limits had random alignment, but since object allocations are always
kTaggedSize-aligned, there is no benefit to having the limit be finer
grained. This patch makes sure that the limit is always aligned, which
in turn implies that the available space in a linear allocation area
is always a multiple of kTaggedSize.
Bug: v8:9700
Change-Id: Ib2980b4b8e792cf516cb734b451862c9e2a98029
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813026
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63895}
This CL allows us to distinguish between the host- and target OS. The
host OS is defined by V8_OS_ macros (e.g. V8_OS_WIN). The target OS is
defined by V8_TARGET_OS_ macros (e.g. V8_TARGET_OS_WIN).
V8_TARGET_OS_ macros are defined by gn, based on the `target_os` gn
variable. If a V8_TARGET_OS_ is set, we also define V8_HAVE_TARGET_OS
(this determines fall-back behavior in V8; if it is not defined, we set
V8_TARGET_OS_ to equal the equivalent V8_OS_ define).
Besides adding the defines, this CL also adds logic to consider the
target OS in codegen. Specifically, x64 builds now look at the
V8_TARGET_OS_WIN define instead of V8_OS_WIN or _WIN64. This
effectively makes cross-compilation to x64 Windows in mksnapshot
possible.
In future work, we could add similar support for cross-compiling to
other platforms such as ia32 Windows.
Bug: v8:9736,chromium:803591
Change-Id: I689f3de8c206b743c4bef703f5ade0bba32ce995
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809374
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63892}
This complements [Shared]ArrayBuffer::GetBackingStore and allows the
embedder to transfer (shared) array buffers using only BackingStores.
Bug: v8:9380
Change-Id: I4714a27e06d5be43aef06dc633f11f2d43e4ee75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1811037
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63889}
It's now set by default if is_msan is set.
Bug: v8:9715
Change-Id: I84e05ff9a495b666292891a12a3ebe485e4a768a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1810558
Auto-Submit: Nico Weber <thakis@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63887}
This reverts commit 6f9b2bd48a.
Reason for revert: Fails on nvidia bots, blocking LKGR: https://ci.chromium.org/p/v8/builders/ci/Win%20V8%20FYI%20Release%20(NVIDIA)/5005
Original change's description:
> [ptr-compr] Make on-heap JSTypedArrays smi-corrupting friendly
>
> On-heap typed arrays contain HeapObject value in |base_pointer| field
> and an offset in |external_pointer| field. When pointer compression is
> enabled we want to combine decompression with the offset addition.
> In order to do that we add an isolate root to the external_pointer value
> and therefore the data pointer computation can is a simple addition of
> a (potentially sign-extended) |base_pointer| loaded as Tagged_t value
> and an |external_pointer| value.
>
> Bug: v8:9706
> Change-Id: Id5c546c353c81fb25e3598921bc78165d10a9c44
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807369
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63874}
TBR=ulan@chromium.org,neis@chromium.org,jgruber@chromium.org,ishell@chromium.org,verwaest@chromium.org
Change-Id: I901280dd191e78d02969600f775c4f0da796921f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9706
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813027
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63886}
There are cases where using VariableList is the way to go, e.g BuildFastLoop.
Change-Id: I0dad242b69145b94725ce206938455127aabeb29
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1806684
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63885}
If predictable compilation is requested (via --predictable,
--single-threaded, or --wasm-num-compilation-tasks=0), do compile and
commit one function at a time. This makes function allocation
independent of the timing.
R=ahaas@chromium.org
Bug: v8:9751, v8:9752
Change-Id: I451a436800c19574caa5e03901bd900d80e53eee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809371
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63884}
This adds an additional V8 API to get the backing store of an array
buffer. Unlike the existing API, the backing store comes wrapped
in a std::shared_ptr, making lifetime management with the embedder
explicit. This obviates the need for the old GetContents() and
Externalize() APIs, which will be deprecated in a future CL.
Contributed by titzer@chromium.org
Bug: v8:9380
Change-Id: I8a87f5dc141dab684693fe536b636e33f6e45173
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807354
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63883}
The promise file is too big so I am splitting it in several CLs.
TNodified:
* AllocatePromiseReaction
* AllocatePromiseReactionJobTask
* AllocatePromiseResolveThenableJobTask
* CreatePromiseResolvingFunctions
* CreatePromiseResolvingFunctionsContext
* CreatePromiseContext
This CL introduces some CASTs that will be deleted once the file is
TNodified in full.
Bug: v8:6949
Change-Id: Ia3006faa5e9fd0e6fa3c58511772857910326532
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809360
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63882}
Added tests for the scenario when the fillers would be evacuated within the
new space and when they would be promoted into the old space.
The fix is to treat the deferred handles the same as the local ones:
call FixStaleLeftTrimmedHandlesVisitor for them.
Bug: v8:9739
Change-Id: Idac233716295f53793657164561bb81f8f729065
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809815
Commit-Queue: Irina Yatsenko <irinayat@microsoft.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63880}
Quasi Fused Multiply-Add and Quasi Fused Multiply-Subtract performs, on floats, a + b * c and a - b * c respectively.
When there is only a single rounding, it is a fused operation. Quasi in this case means that the result can either be fused or not fused (two roundings), depending on hardware support.
It is tricky to write the test because we need to calculate the expected value, and there is no easy way to express fused or unfused operation in C++, i.e.
we cannot confirm that float expected = a + b * c will perform a fused or unfused operation (unless we use intrinsics).
Thus in the test we have a list of simple checks, plus interesting values that we know will produce different results depending on whether it was fused or not.
The difference between 32x4 and 64x2 qfma/qfms is the type, and also the values of b and c that will cause an overflow, and thus the intermediate rounding will affect the final result.
The same array can be copy pasted for both types, but with a bit of templating we can avoid that duplication.
Change-Id: I0973a3d28468d25f310b593c72f21bff54d809a7
Bug: v8:9415
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1779325
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63878}
Disabling the RegExp compilation cache comes with performance implications,
and it doesn't seem to be necessary for debugging.
Bug: chromium:992277
Change-Id: I24841f4814bcacb18a3968c37490f201c0c1ccac
Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg,v8_linux64_gc_stress_custom_snapshot_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1805637
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63876}
WASM only supports Little-endian byte ordering and we need a mechanism to
reverse the ordering efficiently on Big-endian machines.
Up until now this was done using TF graphs within wasm-compiler.
The new approach allows for having more machine level optimizations
by introducing the new "kSimd128ReverseBytes" opcode which gets executed
only on Big-endian machines.
Change-Id: I63c6c3c42ca9ff9d9b2af2d45070a70cf1b3cefc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803494
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#63875}
On-heap typed arrays contain HeapObject value in |base_pointer| field
and an offset in |external_pointer| field. When pointer compression is
enabled we want to combine decompression with the offset addition.
In order to do that we add an isolate root to the external_pointer value
and therefore the data pointer computation can is a simple addition of
a (potentially sign-extended) |base_pointer| loaded as Tagged_t value
and an |external_pointer| value.
Bug: v8:9706
Change-Id: Id5c546c353c81fb25e3598921bc78165d10a9c44
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807369
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63874}
We see crashes in the wild, however the minidump does not contain enough
information for properly investigating this. This is temporary code
that should be deleted as soon as possible.
Bug: chromium:1004365
Change-Id: I25e119d891e03f980d63f5d559fcb4429b574cb1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809373
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63873}
The serialization step in the pipeline gets an initial zone, and thus
far, it's allocated all of it's hinting information in that zone.
However, much of this comes from stepping into calls and
walking the bytecode of the called function. Once we finished
recursing into a call, we should be able to throw all those
hints away -- they've served their purpose, and the "output"
of their work is a set of new objects made visible to the broker.
Therefore, we should create and destroy a child zone.
On a run of typescript, this reduces absolute max (high water mark)
allocation of the serialization phase from 10 MB to 5 MB.
Bug: v8:7790
Change-Id: Icbb35abed28b1a924328541df82be23594152a8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800570
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63872}
This introduces {GetContainingWasmFunction} to replace the above method,
since calculating offsets into the wire bytes is independent of the
concrete module object and hence only needs the shared decoded module.
R=clemensh@chromium.org
BUG=v8:6847
Change-Id: I145d527506289686653979dbb135480cc42ea4c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809369
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63870}
