The fast store handlers create elements and if we have a typed array
on the prototype chain it is not easy to check when it is OK to create
new elements. The TypedArrays swallow all OOB stores, and there is no
easy way to check if the current store is OOB for JSObjects. So use
slow stub when there are typed arrays on the prorotype chain of
JSObjects.
Bug: chromium:1068492
Change-Id: I9eea9cf00e3eb84931c5545d18ba53c4ec39f353
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2134138
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67226}
Previously, one single retained maps list was used across all contexts. When one context was disposed, this entire list of retained maps was disposed as well. This caused maps that were still alive to be disposed leading to deopts when such maps were embedded in code objects.
This patch makes the list of retained maps be per context so we can dispose only the dead maps.
Bug: v8:9684, v8:10431
Change-Id: I0a50f4f49c9f6d72367c62e950828a039220fdfc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122016
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67225}
Deserializer can trigger OOB read in the marking bitmap inside the
RegisterDeserializedObjectsForBlackAllocation function. This happens
for example if an internalized string is deserialized as the last object
on a page and is the turned into a thin-string leaving a one-word filler
at the end of the page. In such a case IsBlack(filler) will try to fetch
a cell outside the marking bitmap.
The fix is to increase the size of the marking bitmap by one cell, so
that it is always safe to query markbits of any object on a page.
Bug: chromium:978156
Change-Id: If3c74e4f97d2caeb3c3f37a4147f38dea5f0e5a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2152838
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67223}
This patch replaces V8's tracing implementation (i.e., the TRACE_EVENT
macros) with the track event base implementation from Perfetto. The
advantages of doing this are:
1) This allows us to remove most tracing-related backend code from V8.
2) V8 can start writing strongly typed trace event arguments, which
are more compact, easier to process and more extensible than legacy
JSON-based trace arguments.
For the time being, we still support the old trace macros when V8 is
embedded into Chrome and other embedders.
Design doc: https://docs.google.com/document/d/1f7tt4cb-JcA5bQFR1oXk60ncJPpkL02_Hi_Bc6MfTQk/edit#heading=h.398p6b4eaen2
Bug: chromium:1006766
Change-Id: Ie71474fbe065821772b13d851487ebbca680c4ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1947688
Commit-Queue: Sami Kyöstilä <skyostil@chromium.org>
Auto-Submit: Sami Kyöstilä <skyostil@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67217}
And a new flag --experimental-wasm-gc, which doesn't do anything yet.
Bug: v8:7748
Change-Id: I927d1d90559249db3ee9f8d240775d45098e52a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154197
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67215}
{StaticCharVector}, according to its name, should return a
{Vector<const char>}. For getting a {Vector<const uint8_t>}, the method
should be called {StaticOneByteVector}, analog to the
{OneByteVector} methods that already exist.
Also, {StaticCharVector} is constexpr, but {StaticOneByteVector} cannot
be, since it contains a {reinterpret_cast}. The same holds for
{Vector::cast} in general.
This CL
- changes the return type of {StaticCharVector} to be
{Vector<const char>},
- introduces a new {StaticOneByteVector} which returns
{Vector<const uint8_t>},
- fixes constexpr annotations at various methods returning {Vector}s,
- refactors users of {StaticCharVector} to either use
{StaticOneByteVector} instead, or work on {char} if that makes more
sense.
R=leszeks@chromium.org
Bug: v8:10426
Change-Id: I71e336097e41ad30f982aa6344ca3d67b3a01fe3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154196
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67213}
Test some constexpr factories. StaticCharVector is not actually
constexpr, this will be fixed in a follow-up CL.
R=leszeks@chromium.org
Bug: v8:10426
Change-Id: I16fdf79cd7d4b3f54d7cf73e15bdff2306810f06
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154192
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67210}
These opcodes are not officially specified yet, they are defined
in the "prototype implementation spec" at https://bit.ly/3cWcm6Q.
Drive-by: drop a unit test whose entire coverage can be provided
by a compile-time check.
Bug: v8:7748
Change-Id: Icefa6dd321802c8a01c4561178b9d21eca1fbaa3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2152841
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67208}
This changelist adds to the GDB stub (in class wasm::gdb_server::Target) the
logic to decode and execute GDB-remote commands and to format response packets
to be sent back to the debugger.
Here most of the commands still act as a NOOP; the actual implementation
requires interactions with the Wasm engine and will be implemented in the next
CL of this series.
Build with: v8_enable_wasm_gdb_remote_debugging = true
Run with: --wasm-gdb-remote
Bug: chromium:1010467
Change-Id: Icfa63be9e1eaa657c05876d0d4e86927e0885b90
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1938466
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67200}
This changelist adds the logic to format, decode, sends and receive packets in
the format specified by the GDB-remote protocol
(https://sourceware.org/gdb/onlinedocs/gdb/Overview.html#Overview).
Build with: v8_enable_wasm_gdb_remote_debugging = true
Run with: --wasm-gdb-remote
Bug: chromium:1010467
Change-Id: Ibc9c6713c561d06847b472fab591c208c193199f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1929409
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67196}
A new realm doesn't contain the mocks and suppressions on the global
object for correctness fuzzing. We replace Realm.eval with eval to
keep exercising the code.
Bug: chromium:1071133
Change-Id: Iffe82d37bf08829fc5937c17c2089277403e71dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2153206
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67187}
SIMD opcodes consist of the prefix byte, then an LEB128 encoded int. We
were decoding this incorrectly as a fixed uint8. This fixes the decoder
to properly handle multi bytes.
In some cases, the multi byte logic is applied to all prefixed opcodes.
This is not a problem, since for values < 0x80, the LEB encoding is a
single byte, and decodes to the same int. If the prefix opcode has
instructions with index >= 0x80, it would be required to be LEB128
encoded anyway.
There are a bunch of trivial changes to test-run-wasm-simd, to change
the macro from BUILD to BUILD_V, the former only works for single byte
opcodes, the latter is a new template-based macro that correct handles
multi-byte opcodes. The only unchanged test is the shuffle fuzzer test,
which builds its own sequence of bytes without using the BUILD macro.
Bug: v8:10258
Change-Id: Ie7377e899a7eab97ecf28176fd908babc08d0f19
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2118476
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@{#67186}
This is a follow-up fix for https://crrev.com/c/v8/v8/+/1491608
Bug: chromium:1051186
Change-Id: Ia76ad0e7665fe17013b45816350238c35e7199f6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2049899
Reviewed-by: Frank Tang <ftang@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Auto-Submit: Yury Semikhatsky <yurys@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67184}
- Adds kFPReturnRegister0 for all platforms.
- Reworks linkage.cc to assign return registers to the proper
register type, using the new FP return register.
Bug: v8:10070
Change-Id: I5c876d248de9b825a1c80847ab134881dcda6f04
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2107510
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67183}
These tests were skipped three years ago because of flakes. I cannot
reproduce the flakes any more, so reenabling the tests.
R=petermarshall@chromium.org
Bug: chromium:772010
Change-Id: I4dc2d890b20e642f8d9351676aecab965d2b4b63
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151357
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67182}
When we create a new elements array we should initialize it with holes.
The capacity of the newly created elements array could be greater than
the actual length of the array and we expect the unused slots to be
filled with holes.
Bug: chromium:1070560
Change-Id: Ia365eed59859e36a9c8b9e27be34f93ab88942bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2150599
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67180}
This CL relands the implementation of the __getLocal and __sbrk APIs of
the evaluator interface reverted in efea740. Update the original
commit to account for a changes to the import function name tracking and
defaulting to debugging with liftoff.
Change-Id: I9674aad419fb1dab0a9ecbb5d3fd4c33186b127a
Bug: chromium:1020120
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151353
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67178}
The failure was probably the same as in https://crbug.com/v8/10410. Thus
reenable the test also in the stress_incremental_marking variant on
windows.
R=thibaudm@chromium.org
Bug: chromium:772010, v8:10410
Change-Id: Iad0b9b60408e08c5f2202462f6eeba3067525ae5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151356
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67176}
On-heap TypedArrays have empty ArrayBuffers that are not supposed to be
accessed directly. Such ArrayBuffers materialize properly when accessed
via their TypedArrays.
The queryObjects() sidesteps the bottleneck and finds empty ArrayBuffers
by iterating the heap. When preview TypedArrays are constructed for the
found ArrayBuffers, they get nullptr data pointers.
This CL converts all on-heap TypedArrays into off-heap TypedArrays in
queryObjects to make sure that all found ArrayBuffers are valid.
Bug: chromium:992442
Change-Id: Ie77d1e75aa2007b4a976c72206b9a4e215c9ef53
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2150601
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67174}
Change-Id: Ic5dbf4c3330c71cbae73aa07b2adb1c8ac087182
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151348
Auto-Submit: Georg Neis <neis@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67172}
This adds support for custom weak callbacks through static callbacks and
instance methods.
Bug: chromium:1056170
Change-Id: Ie4bd32539e0d933b192f07edb2d45e0070c2128d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2148784
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67167}
To avoid shrinking the unregister token map on each pop of the cleared
cell list, the Torque implementation of the cleanup loop avoids
shrinking the map until the end of the loop.
To support that, PopClearedCellHoldings is refactored to the Torque
PopClearedCell which calls the
JSFinalization::RemoveCellFromUnregisterTokenMap and the runtime
ShrinkFinalizationRegistryUnregisterTokenMap. The former cannot GC is
and is implemented in CSA as a fast C call. The latter can GC and is a
runtime call.
This also incidentally makes uses of FinalizationRegistry without
unregister token a fast path that doesn't have to leave Torque.
Bug: v8:8179
Change-Id: Ia0c3c5800d26e31319a818f164f6bd3267355aa6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2137950
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67161}
Soft-deopt for mono/polymorphic property accesses that don't have any
maps, and only allow zero-map feedback to be monomorphic. This makes
sure we only emit a megamorphic LoadIC builtin call if the IC was
actually megamorphic.
JSGenericLowering assumed that zero maps meant that a load site is
megamorphic. However, it can be the case that the call-site is
monomorphic or polymorphic, and the maps had died. In this case we don't
want to call the megamorphic IC builtin, as on a stub cache miss we
fallback to a normal LoadIC miss, which can record mono/polymorphic
feedback in the IC. After this, we'll enter a miss loop in the
megamorphic load builtin, and worse the LoadIC assumes that there's
something "wrong" with the feedback, so it'll keep trying to reconfigure
the handler (possibly allocating new load handlers if this is a
prototype field access).
As a drive-by, rewrite GetRelevantReceiverMaps to be an in-place
filtering of the maps rather than copying them.
Change-Id: I0c25bfa606367fa81c43223bbd56cdadb5e789ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2150586
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67152}
In strict mode stores to non-existent properties throw. We should not
install a handler with the property cell for such stores. These handlers
would expect that the value exists when they see a property cell. If
this property cell gets invalidated later, it appears as if it is a
valid property cell with undefined value. This leads to an incorrect
behaviour. This cl checks if we are in strict mode and uses a slow
stub in such cases.
Bug: chromium:1067757
Change-Id: I543c6a6931530bfb13cc9a33d1dabaa756489fd1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2142255
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67151}
Add ConcurrentAllocator which can be used for concurrent allocation from a background thread in the old space. ConcurrentAllocator doesn't request a GC yet when an allocation fails. This will be implemented in later CLs.
Bug: v8:10315
Change-Id: I81260ebbd8863c143e93aedb93c66d0e7c28bddb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144066
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67150}
Bug: chromium:1070890
Change-Id: I62ad81b8d5bcb9934c7eda4eae595d41339adfdf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2149425
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67147}
The underlying issue was fixed in https://crrev.com/c/2144116 and
https://crrev.com/c/2142259. This reenabled the test generally. Note
that it's still skipped in special configurations. I will reevaluate
which of those can also be unskipped via separate CLs.
Drive-by: Fix the order of "expected" and "actual" values.
R=thibaudm@chromium.org
Bug: v8:10410
Change-Id: Idbdcc73d641661e96e12110dcf10b060e0cf47a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144070
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67145}
When memory.grow was executed concurrently on multiple threads a data
race could happen such that two memory.grow operations result in the
same return value. With this CL the return value of memory.grow is
unique, given that memory.grow actually grows the memory.
As a concrete example, assume a shared WebAssembly memory initially has
a size of 100. Assume two threads call memory.grow concurrently with a
parameter `10`. Then with the existing code, memory would grow correctly
to a size of 120, but the data race may cause both memory.grow
operations to return 100. With the change in this CL one memory.grow
operation would return 100, the other would return 110.
R=gdeepti@chromium.orgCC=rreverser@google.com
Bug: chromium:1067621
Change-Id: Ib22b5135714a56799e0818ccb39e5dce327e5f8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144113
Reviewed-by: Ben Smith <binji@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67135}
AIX default page size is 4096 bytes hence
PlatformUsesGuardPages returns true. Power Linux however
has a default page size of 65536 bytes and the above function
is expected to return false. More info is available
at https://crrev.com/c/2144060.
Change-Id: I35a13ada5bd1b18729cfa039a0bc699a409fbc2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2147634
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#67134}
A few notes:
1) Oilpan is a generic library, meaning that it can work with arbitrary
user types. The library is split in type-aware (include/) and
type-erased (src/) parts. The former comprises a lot of code that still
needs to be defended with dchecks;
2) Macros are prefixed with CPPGC_, so that they don't clash in the user
code with similar macros from other libraries;
3) The macros simply forward requests to V8 so that dcheck handlers can
be configured uniformly;
4) The CL doesn't contain CHECK_EQ and friends, but they can be added
later if needed.
Bug: chromium:1056170
Change-Id: I68e6f663247705233eaf030384164d81e53071e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2148774
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67129}
This reverts commit f2ea42d6b8.
Reason for revert: Makes UBSan unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10634
Original change's description:
> [wasm-debug-eval] Implement additional evaluator API methods
>
> This CL implements the __getLocal and __sbrk APIs of the evaluator
> interface. Also includes a drive-by fix of the imports' module: put
> them on the "env" module.
>
> Change-Id: Ie16d1b1cf924b88734eda184d1ce98d52f32f828
> Bug: chromium:1020120
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2132786
> Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67122}
TBR=jkummerow@chromium.org,pfaffe@chromium.org
Change-Id: I23b078d37971e083c08c9b83994bbf38ac13f103
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1020120
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2148787
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67124}
This CL implements the __getLocal and __sbrk APIs of the evaluator
interface. Also includes a drive-by fix of the imports' module: put
them on the "env" module.
Change-Id: Ie16d1b1cf924b88734eda184d1ce98d52f32f828
Bug: chromium:1020120
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2132786
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67122}
For example, when --fuzzing is off, %OptimizeFunctionOnNextCall now
crashes when given a non-function argument.
The following behaviors remain unchanged for now:
- %DeoptimizeFunction continues to do nothing if the function is not
optimized.
- %DeoptimizeNow continues to do nothing if the top-most JS function
is not optimized.
- %OptimizeOSR continues to do nothing if the function already has
optimized code.
Bug: v8:10249
Change-Id: I35d2f3d50ce3f94c8ffccabe50fb4df2b70ce028
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2137406
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67121}
This adds a flag to {WasmCode} objects to store whether this code was
generated for debugging. This flag can be set for Liftoff code (in which
case the code will e.g. have an extended prologue for debugging), but it
can also be set for TurboFan, in case Liftoff bailed out when producing
the debugging code.
Having this flag allows us to remove the hack to pass the compilation
results to {OnFinishedUnits} just to check whether we actually wanted to
compile Liftoff functions.
Drive-by: Replace the {ReachedRecompilationTierField} by a
{MissingRecompilationField}, because all we need to know is if we are
still waiting for that function to get recompiled.
R=ahaas@chromium.org
Bug: v8:10330,v8:10410
Change-Id: Ia023df8955a60d9f5595a6cb2737e14d83baf716
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2142259
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67119}
This is a port of src/components/gc that was added recently.
Differences:
- Added back bucketing to the page pool, as that guarantees that
arenas used for specific types do not have their pages used by other
arenas.
- Replaced base::flat_map with std::map. This may cause performance
regressions when using PageMemoryRegionTree in hot paths. A
vector-like representation may be used to fix such a regression
This reverts commit a056cea51e.
Bug: chromium:1056170
Change-Id: Iffb8b0d91c8cca1815d7a1cda9486e7716aea75f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144060
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67117}
Before the "debug" flag was stored on the {CompilationEnv}. But each
background compilation task only gets the {CompilationEnv} once when
starting compilation, so by the time it picks up the "Liftoff for
debugging" compilation jobs, it might still compile them without the
debug flag being set. This leads to flakes in the "debug-step-into-wasm"
test, because we won't stop in the function prologue when stepping in
(because the function prologue does not check the "hook on function
call" flag if debug mode was not enabled).
This CL does not increase the size of a compilation unit, since both the
tier and the debug flag only need a single byte each.
As a nice side effect, this change allows us to remove the lock in
{CreateCompilationEnv}, because no modifyable flag is read any more.
R=thibaudm@chromium.org
Bug: v8:10410
Change-Id: Ic296ea0c4dd1d4dedde119f0536e87e5d301b5a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144116
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67115}
Change the unittests Isolate mixin to create one Isolate per test,
rather than one per test suite. We usually run these tests independently
in separate processes anyway, so this shouldn't affect normal test
execution, but it will avoid Isolate state leaking across tests when
running the unittests binary directly.
Take this opportunity to also clean up the mixins, changing counter
initialization and forcing pointer compression into template traits.
Bug: v8:10142
Change-Id: If92046f9c6f2056252d099faed04d97844ef7319
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2143818
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67110}
Provides the infrastructure to register weak callbacks for
WeakMember<T> through visitor. The WeakCallbackInfo broker is used to
query objects for liveness. In a future CL the same broker object is
passed to custom weak callbacks.
Change-Id: I8b5a66354e0e457521989d40ae64a9558c339503
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2142265
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67109}
