HeapBase::CollectStatistics returns a HeapStatistics struct that can be
used by blink to populate a memory dump.
Bug: chromium:1056170
Change-Id: Ic147a02ba6b4aa77bf92cfca067da70b7e1af55b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689181
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72660}
WrapperDescriptor is used to describe how JS wrapper objects can be
inspected to find C++ wrappable objects. In addition, to specifying
which embedder fields are used to find type and instance, the
descriptor also provides and embedder id that identifies
garbage-collected objects. It is expected that the first field of the
type is a uint16_t with that id.
Bug: chromium:1056170
Change-Id: I9cf8d79db972f2dea023114fd5a567e89a3bf373
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688399
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72657}
This bug was flushed out while working on refactoring the stack traces
(as part of https://crrev.com/c/2689183).
Bug: v8:8742
Change-Id: I5bbd4066cc464b71f4d9a7c90acc35e8cef7afb3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689193
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72653}
This is a reland of da785659be
The reland overrides ShouldHaveBeenSerialized for typed array
refs to avoid disabling related optimizations when direct heap
access is enabled.
Original change's description:
> [compiler] Don't serialize JSTypedArray fields
>
> This CL removes serialization of JSTypedArray fields when direct heap
> reads are enabled. Invariants we rely on:
>
> - Of the underlying interesting fields,
> - base_pointer and external_pointer are set either during
> initialization, or in a one-time on-to-off-heap transition in
> GetBuffer.
> - length and buffer are immutable after initialization.
> - is_on_heap and DataPtr derive from base_pointer and
> external_pointer s.t. is_on_heap == (base_pointer != 0) and
> DataPtr == external_pointer in the off-heap case.
>
> In this CL we add one new invariant:
>
> - For all base_pointer and external_pointer mutations after
> initialization, base_pointer is guaranteed to be release-stored
> after external_pointer has been written.
>
> With these invariants, concurrent access to off-heap typed arrays is
> trivial as long as is_on_heap (= base_pointer) is read before other
> relevant fields.
>
> Note that JSTypedArray remains a kSerializedHeapObject due to the
> serialized superclass JSObject.
>
> Drive-by: Remove unused Torque operators and empty TODOs.
>
> Bug: v8:7790
> Change-Id: I3c4327318f94e4e6083d4e87476069aad2649386
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679689
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72572}
Bug: v8:7790
Change-Id: I87b37de983e8cf89ca53b5efae7ab195781f3df5
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689182
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72652}
This reverts commit 2a446a9058.
Reason for revert: This caused regressions on Octane / Jetstream2 /
Sunspider and a couple of regressions on memory usage on mobile:
https://bugs.chromium.org/p/chromium/issues/detail?id=1177124https://bugs.chromium.org/p/chromium/issues/detail?id=1177241
Original change's description:
> Enable FLAG_feedback_allocation_on_bytecode_size
>
> This flag enables feedback allocation heuristics to be based on the
> function size. The threshold for feedback allocation is set to
> 4 * bytecode size to roughly mimic the allocation after 4 invocations.
>
> Change-Id: Ia840cd526e3718d4267e01c688c6c6467e352d72
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685175
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72631}
TBR=rmcilroy@chromium.org,mythria@chromium.org,verwaest@chromium.org
Change-Id: Ib756116aa38117c06e95c7f68d8f9ba0acd34084
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689194
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72651}
Additional arguments are allowed along with the reference, but the
targeted branch must have at least one output (corresponding to the
cast reference).
Bug: v8:7748
Change-Id: I17383165e4bae1cada1676c6282437e1fa71905d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685161
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72649}
If a script was shared between multiple modules (because they used the
same wire bytes) it could happen that we still triggered multiple
"scriptParsed" events via CDP. This was because
{WasmEngine::GetOrCreateScript} did not communicate back whether it
used a cached script or whether it created a new one.
This CL moves the call to {Debug::OnAfterCompile} (which triggers the
"scriptParsed" event) to the {WasmEngine::GetOrCreateScript} method,
such that we only call it once per script.
Since the engine only holds a weak reference to the script, we would
still trigger multiple events if the script is garbage-collected in the
meantime. In this case there is no way around this, as the new script
would have a new ID, hence we need to emit a new event to make it
public to the debugger.
R=thibaudm@chromium.orgCC=bmeurer@chromium.org
Bug: chromium:1151211
Change-Id: I1a7986514fd708680541a0e5dc24e60f01f42c28
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_mac64_gc_stress_dbg_ng
Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2687755
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72648}
For a long time, V8 had two distinct ways to capture and store a stack
trace, one where we'd just collect and symbolize the information for the
v8::StackTrace API (script id, name, line and colum information mostly),
and one where V8 would also memorize the closures, receivers, and
optionally the parameters of the stack frame, which we use for
Error.stack and the non-standard CallSite APIs. Those two were often out
of sync and suffered from various different issues. Eventually they were
refactored into a single captureStackTrace() bottleneck that would
produce a FrameArray.
This CL is a logical continuation of the refactorings. It repairs a
regression where we'd compute the method name (as part of the
cached StackFrameInfo) even if we don't need them (as is the case for
the inspector and any other use of the v8::StackTrace API).
Everytime a method was invoked on StackTraceFrame, it'd call into
StackTraceFrame::GetInfo(), which would lazily setup the StackFrameInfo
like this:
1. Create a FrameArrayIterator and point it to the FrameArray at the
index stored in the StackTraceFrame.
2. Invoke FrameArrayIterator::Frame(), which copies the information
from the FrameArray into a temporary JSStackFrame, AsmJsStackFrame
or WasmStackFrame C++ object, and use the StackFrameBase virtual
methods to transfer all information to a newly created
StackFrameInfo object.
3. Kill the link to the FrameArray and put a link to the
StackFrameInfo object into the StackTraceFrame.
This caching turned out to be extremely costly, since beyond other
things, it'd always invoke JSStackFrame::GetMethodName(), which is
extremely costly (the execution time is linear in the number of
properties on the receiver and it's prototype chain). The cost was so
high that several work-arounds had been added, which would avoid
triggering the eager construction of the StackFrameInfo object (i.e.
https://crrev.com/c/2080663, https://crrev.com/c/2550504 or
https://crrev.com/c/2261736, but also https://crrev.com/c/1688927).
This CL removes the StackFrameInfo caching completely, since neither the
inspector nor Error.stack benefit from the caching at all. It's only the
first part in a series of refactorings that will significantly reduce
the complexity and overhead of the stack trace collection.
Doc: https://bit.ly/2wkbuIy
Bug: chromium:1057211, chromium:1077657, chromium:1069425, v8:8742
Bug: chromium:1127391, chromium:1098530, chromium:981541
Change-Id: I8edb8ff48b620eb3043ae51ab4ea27146ef0a5a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689185
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72647}
Make main-thread handle allocation fail more gracefully when run on
background threads.
Bug: v8:10315
Change-Id: Iece9215aed21020b97fede40d78ea56b9baffac4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689184
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72646}
V8 implements a fast-path for RegExp.prototype.split which diverges
from the spec: instead of creating a new sticky regexp instance
`splitter` and running it in a loop, we reuse the existing non-sticky
regexp without looping through each character.
This works fine in most cases, but we run into issues when matching at
the very end of the string. According to the spec, matches at the end
of the string are impossible in @@split, but in our fast-path
implementation they can happen.
The obvious fix would be to remove our fast-path but this comes with
high performance costs. The fix implemented in this CL adds a special
flag to `exec` s.t. matches at the end of the string can be treated as
failures. This is only relevant for @@split.
Bug: chromium:1075514
Change-Id: Ifb790ed116793998d7aeb37e307f3f3f764023d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2681950
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72644}
Also move it from post-mvp to mvp, since it is now in the proposal.
Bug: v8:11002
Change-Id: I711ee7a92e6937948c93e6028ef018188ea4c976
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676937
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72643}
Vector register lane numbers on IBM machines are reversed
compared to x64. For example, doing an I32x4 extract_lane with
lane number 0 on x64 will be equal to lane number 3 on IBM machines.
Vector registers are only used for compiling Wasm code at the moment.
Wasm is also little endian enforced. On s390 native, we manually do
a reverse byte whenever values are loaded/stored from memory to
a Simd register. On the simulator however, we do not reverse the bytes
and data is just copied as is from one memory location to another
location which represents a register. To keep the Wasm simulation
accurate, we need to make sure accessing a lane is correctly simulated
and as such we reverse the lane number on the getters and setters.
We need to be careful when getting/setting values on the Low
or High side of a simulated register. In the simulation, "Low" is
equal to the MSB and "High" is equal to the LSB on memory.
As a result, many of the "#ifdef V8_TARGET_BIG_ENDIAN" blocks on
Simd opcodes are not needed anymore as we are now simulating
native behaviour.
Change-Id: Idfa80cdef7382febb4311c75eb6d3e1d110141fa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2687756
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Reviewed-by: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#72642}
Extract codegen into macro-assembler functions for reuse in Liftoff.
Some minor tweaks in I32x4TruncSatF64x2SZero and I32x4TruncSatF64x2UZero
to check dst and src overlap and move to scratch/dst accordingly. In
TurboFan we can set these restrictions in the instruction-selector, but
not in Liftoff. This doesn't make TurboFan codegen any worse, since
those restrictions are still in place.
Bug: v8:11265
Change-Id: I48f354c5ff86809bb3ddc38eca6dc8990b9b7d61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683208
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72641}
This reverts commit a16add806d.
Reason for revert: Broke Win32 debug https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32%20-%20debug/29653/overview
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}
TBR=bbudge@chromium.org,zhin@chromium.org
Change-Id: Idbfc8cd0fbbff607cff76953c53d0c149b87b573
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:11415
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688074
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72640}
Extract codegen into macro-assembler functions for reuse in Liftoff.
Some minor tweaks in I32x4TruncSatF64x2SZero and I32x4TruncSatF64x2UZero
to check dst and src overlap and move to scratch/dst accordingly. In
TurboFan we can set these restrictions in the instruction-selector, but
not in Liftoff. This doesn't make TurboFan codegen any worse, since
those restrictions are still in place.
Bug: v8:11265
Change-Id: Ib6b3ebeb5fed99eddd0700fb4aba91d4168c3213
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683206
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72638}
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}
This reverts commit 60748ee2df.
Reason for revert: Broke Linux64 ASAN https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20ASAN/38792/overview.
There are 4 changes in that range causing the failure, I found that this change caused the failure by running locally `./tools/run-tests.py --outdir=out/repro mjsunit/wasm/gc-stress --variant turboprop_as_toptier --random-seed-stress-count 100`.
Original change's description:
> Reland "[interpreter] Speed up the BytecodeArrayAccessor through direct memory access"
>
> Tbr: ulan@chromium.org, neis@chromium.org, leszeks@chromium.org
> No-Presubmit: true
> Change-Id: I4ceb9e21ac7d78a87776b4be174772539d2da8d9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685173
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72632}
TBR=ulan@chromium.org,neis@chromium.org,leszeks@chromium.org,verwaest@chromium.org
Change-Id: I441ddfda5d852b7a01f38a9e60edc56f40ae626a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2686266
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72635}
This flag enables feedback allocation heuristics to be based on the
function size. The threshold for feedback allocation is set to
4 * bytecode size to roughly mimic the allocation after 4 invocations.
Change-Id: Ia840cd526e3718d4267e01c688c6c6467e352d72
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685175
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72631}
Model cppgc::InitializeProcess()/cppgc::ShutdownProcess() similar to
V8's InitializePlatform()/ShutdownPlatform() in that we allow the pair
to be called multiple times.
GCInfoTable will not be freed on ShutdownProcess though as the current
global design uses static indices to retrieve per-type metadata.
Drive-by: Remove stale ShutdownProcess() call.
Change-Id: Ia9b50325a964e85a72f3ef218e72bc386b69be51
Bug: chromium:1176416, chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685171
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72630}
With top-level await, when Evaluate is performed on an already-evaluated
synthetic module, Module::InnerEvaluate returns undefined. This breaks
top-level await's assumption that the returned value is always a
promise.
In order to make SyntheticModule's behavior consistent with
SourceTextModule, the top_level_capability field is moved up to Module
and SyntheticModule::Evaluate places the promise returned from the
host's evaluation steps in that field. Now SourceTextModule and
SyntheticModule can share the same code to handle the case where the
module is either kErrored or kEvaluated, so the code for this
is moved up to Module.
Thus, SyntheticModule is now guaranteed to return the
promise from the evaluation steps even on subsequent Evaluate() calls.
Unfortunately Node hasn't yet updated their EvaluationStepsCallback
to return a Promise, so we can't yet assume that the returned value
is a Promise without breaking Node. So, this change also adds a clause
to check for this condition and create a new resolved Promise if one
was not provided by the callback steps. This could eventually be
removed once Node's callback steps are updated for top-level await.
Change-Id: I2d6ae918abfeba9e3a757838502d4df92946edaa
Bug: v8:11398
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2673794
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72629}
The implementation is similar to the callbacks that already exist for
the origin trial for WebAssembly simd.
Bug: v8:8091
Change-Id: I969b68c209ea62cf70dbaf317616300b782b5e14
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2672020
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72628}
Previously in https://chromium-review.googlesource.com/c/v8/v8/+/2545573
I updated BasicBlockInstrumentor to use 64-bit floating-point values
rather than 32-bit integers, so that it could never overflow. However,
I've now learned that some builtins (particularly RecordWrite) are not
allowed to use floating-point registers, and so running with
basic block instrumentation enabled could produce incorrect results.
This change switches back to 32-bit integers, but adds saturation logic.
Bug: chromium:1170776
Change-Id: Icbd93919fb05f50d615ec479263142addbe15c9e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685617
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72626}
Dropping the gpu:none dimension broadens the choice of Mac bots from
so far only 8-core VMs to also include 4-core and 12-core Mac Minis.
This CL adjusts the shard configs to account for adding
4-core Mac Minis to the choice.
We also skip a test that's slow only on 4-core bots.
No-Try: true
Bug: chromium:1174040,v8:11418
Change-Id: Ic0be0db197341b7b8f88eb30aa284c38b0e69609
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685164
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72623}
Reorganize shards to account for recent timeouts on the Android
builder. Also ensure we test the same thing on trybots and CI.
No-Try: true
Bug: v8:11428
Change-Id: If245999e0d2e20ecb7f0ee640be5d98f1c90ff64
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685165
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72622}
If an attempt to tiering up fails (for ex: there is not enough space
to enqueue a job) then use the existing optimized code from a lower
tier. Currently we just install interpreter entry trampoline as the
function's code object. Though InterpreterEntryTrampoline checks for
any existing optimized code and installs it on the closure, just
returning it from here saves us these additional checks.
Bug: v8:9684
Change-Id: I62b4bc3b114bbbc9b0702cc9e831a3dfb4b37761
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2682645
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72621}
By disengaging it from 'let' which is not implemented in liftoff yet.
Bug: v8:7748
Change-Id: I191695767bf8c6153f70d509dd13ff734fe75e01
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676631
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72620}
This reverts commit 42cd9eb78d.
Reason for revert: Clusterfuzz issues, e.g.
https://bugs.chromium.org/p/chromium/issues/detail?id=1176318
Original change's description:
> [compiler] Directly read PropertyCells
>
> Main changes:
>
> - Introduce a new broker data kind kBackgroundSerialized for objects
> that can be serialized in the background (when direct reads are on).
> (I'm planning to remove kPossiblyBackgroundSerialized in a followup,
> in favor of a dynamic choice of kSerialized or kBackgroundSerialized).
> - Make PropertyCell use that new kind.
> - Introduce a bottleneck in runtime code for changes to PropertyCells
> and make sure that a certain protocol is followed that allows
> concurrent reads from the background thread.
> - Improve interface of PropertyCell in various ways.
>
> Bug: v8:7790
> Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72586}
TBR=ulan@chromium.org,neis@chromium.org,verwaest@chromium.org,nicohartmann@chromium.org
Change-Id: Id04145760c49fa379bc5a3fc16eba664025a9180
Bug: v8:7790
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685125
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72619}
TimeToSafepoint is the time needed for all background threads to enter
a safepoint after the GC was started on the main thread. This CL
improves that metric during concurrent compilation to bytecode by doing:
1) Park the LocalIsolate during
InterpreterCompilationJob::ExecuteJobImpl. There are no concurrent
heap accesses happening while generating bytecode for now. So instead
of manually placing Safepoint() invocations in the code, simply park
the local isolate.
2) Destroy the LocalIsolate before the ReleaseParser operation. I've
seen this take around 2ms, which regressed TimeToSafepoint a lot.
3) Add explicit safepoints to concurrent allocations. This covers the
rest of the code and from what I've seen so far this is good enough
to keep TimeToSafepoint around a few microseconds.
I've still seen TimeToSafepoint events with 20-80 microseconds but those
were quite rare and always seemed to be related to Turbofan.
AsLocalIsolate() is necessary in generic code to convert both Isolate
and LocalIsolate to LocalIsolate.
Bug: v8:10315
Change-Id: Idaf9f04ffdf850d0ab0081ec372cc384a9fe7ef9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2663159
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72618}
This reverts commit 5cc7bfd04c.
Reason for revert: Need to revert dependency.
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=neis@chromium.org,solanes@chromium.org,nicohartmann@chromium.org
Change-Id: I48a96504c29851587529d7d12cb15e569aec196b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7790
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685124
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72617}
Extract i8x16.popcnt implementation into a macro-assembler function, and
reuse it in Liftoff.
We need an additional temporary XMMRegister whose lifetimes overlap with
dst and src, so make sure to pin those 2 when getting an unused
XMMRegister.
Bug: v8:11002
Change-Id: I13400b139add6f12316b3f398a796e6bf5a1ea7f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676921
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72615}
This is a reland of 00babf0718
No changes from original patch, previous CQ failures were likely
a Mac infra issue https://chromium-review.googlesource.com/c/2682521.
Original change's description:
> [wasm-simd][x64][liftoff] Implement i8x16.popcnt
>
> Extract i8x16.popcnt implementation into a macro-assembler function, and
> reuse it in Liftoff.
>
> Bug: v8:11002
> Change-Id: I86b2f5322c799d44f584cac28c70e0e393bf114f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676280
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72565}
Bug: v8:11002
Change-Id: Ic8bcbdb3444865805d8d2af3669ccb4a05c4426d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2682507
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72614}
This is a partial revert of https://crrev.com/c/2457669/.
This change is slightly longer (in code-generator-x64.cc) because we
also implement support when SSE4_2 is not supported (the reverted change
seems to assume SSE4_2, which is not always the case). This code
sequence is from https://github.com/WebAssembly/simd/pull/412.
Bug: v8:11415
Change-Id: I3eef415667b4142887cf1c449d27d19ba5bbd208
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683219
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72611}
