This reverts commit dcac02ee81.
Reason for revert: TSAN discovered issue with cleaning invalidated slots in sweeper threads and inserting new slots in the main thread.
Original change's description:
> Use list of invalidated objects for old-to-new refs
>
> Instead of inserting "deletion" entries into the store buffer, keep
> a list of invalidated objects to filter out invalid old-to-new slots.
>
> Bug: v8:9454
> Change-Id: Icd21d8cb2159190457f54d0f8b56742ecc820419
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695474
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62744}
TBR=ulan@chromium.org,petermarshall@chromium.org,dinfuehr@chromium.org
Change-Id: I4278e9100c76657663e0a6a62f5d86bb3a343c0e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9454
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704109
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62746}
In particular, some methods were public even though they should have
been protected/private (FreeListCategoryType), and some other methods
were declared but not defined (SearchForNodeInList).
Bug: v8:9329
Change-Id: I7a1e97c82395c5907b750d89057b37b64bc0c253
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704096
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@google.com>
Cr-Commit-Position: refs/heads/master@{#62745}
Instead of inserting "deletion" entries into the store buffer, keep
a list of invalidated objects to filter out invalid old-to-new slots.
Bug: v8:9454
Change-Id: Icd21d8cb2159190457f54d0f8b56742ecc820419
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695474
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62744}
This CL changes how the start and end address for the iteration are
retrieved from an std::vector that won't cause a failed assertion.
There are some std::vector implementations that contain bounds checks.
The string table iteration code uses an access like
{&young_strings_[young_strings_.size()]} to retrieve the end address
for an iteration. This results in a out of bounds exception on such a
std::vector implementation even though the "element" itself is not actually
accessed.
Change-Id: I31db8994a7ff613897ad9deac953a1ee91f322b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704097
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62742}
Port 56eaec9d49
Original Commit Message:
We had both jump slots and lazy compile slots in the same table. This
increases the space per slot to the maximum of the two, even though we
often do not use lazy compilation and could have smaller jump slots.
This CL splits the two into two separate tables. The lazy compile table
will only be created on demand, and will never be patched.
The jump table now only contains jumps, and is more compact (which
might improve performance because of improved locality).
R=clemensh@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I7bece77c02f8075da54d664215989339f2958ccd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1702126
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#62740}
On newer compilers the {operator delete} with explicit {size_t}
argument would be instantiated for {WasmInstructionBuffer} and used
in the destructor of {std::unique_ptr<WasmInstructionBuffer>}. The
{size_t} argument is wrong though, since the pointer actually points
to a {WasmInstructionBufferImpl} object.
The solution is to explicitly provide a {operator delete}, preventing
an implicitly generated {size_t} operator.
R=clemensh@chromium.org
Change-Id: I2cc22078d03a523121309bae94f5b612cb98e112
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1702613
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62737}
perfrunner returns a failure if the build timeouts at any point even if it's
successful after retries. It tries to surface up the timeout issue. Due to this,
some bots stay red consistently, and confuses the sheriffs.
This CL masks the timeouts if the suite succeeds in the end.
TBR=verwaest@chromium.org,sergiyb@chromium.org
Bug: v8:9494
Change-Id: I8e107e80dfaa51095501bb2e855d9fbbe4023da9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1702612
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Auto-Submit: Tamer Tas <tmrts@chromium.org>
Commit-Queue: Tamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62735}
This CL adds a new FreeList strategy, that can be turned on by using
flag `--gc-freelist-strategy=2`. It uses a lot (about 50)
FreeListCategories instead of the 6 ones used in FreeListLegacy.
Allocation is done using a best-fit strategy. However, FreeListMany
could be subclassed in order to change the allocation strategy while
still using the same freelists.
Using this strategy is expected to reduce memory usage but to also
reduce allocation performances.
Bug: v8:9329
Change-Id: I201be863270a3287701fefdd9e14ba7849a8a551
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698392
Commit-Queue: Darius Mercadier <dmercadier@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62731}
iOS uses 16kb memory pages. This change modifies OS::GetRandomMmapAddr()
to return a 16kb-aligned address on apple ARM64.
The mrs instruction is invalid on iOS. This change modifies
CacheLineSizes::CacheLineSizes() so that mrs is not executed.
Change-Id: I13fcc8498e715c03432c7a652ee723660f746069
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701127
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62730}
Private getters and setters are not implemented in v8 and are skipped
already.
Bug: v8:9430
Change-Id: Id59c0757d90ab94b828e5fc7c254d6f209796eea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1702242
Auto-Submit: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62722}
The context was not set during streaming compilation.
The initial upload is the original CL and patch set 1 is the fix.
Original CL:
> [wasm] Compile JS to WASM wrappers asynchronously
>
> R=mstarzinger@chromium.org, ahaas@chromium.org
>
> Bug: v8:9231
> Change-Id: I9e18073bbe25bf8c9c5f9ace102316e6209d0459
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1669699
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62672}
R=mstarzinger@chromium.org, ahaas@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux_blink_rel
Bug: v8:9231
Change-Id: I61fc11a6de54cc6e93f3600487a89fa5d2350f0e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701850
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Auto-Submit: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62721}
If the lookup of the resolve property on the constructor throws, we
need to call IteratroClose before rejecting the promise.
Bug: v8:9431
Change-Id: Idb33ffe09d339723ef0cd2469335598ab27b49bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701857
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62720}
This change is mostly mechanical, but it's worth mentioning a few
slightly interesting cases:
- A couple of field definitions didn't match the signedness of their
corresponding accessors.
- The generated accessors for Smi data use Smi values directly, but
usually we want C++ accessors to use ints instead. I added a macro
that hides the generated Smi accessors and exposes int accessors,
but we might consider generating int accessors directly.
- The data held in some fields is described in comments next to the
accessor definition for those fields. With automatically generated
accessors, those comments need a new home. In this change I put them
in the Torque object definition, but I'm open to other suggestions.
- gen-postmortem-metadata couldn't find updated class definitions after
they got split across multiple lines, so I changed its matching
logic. (Ideally debug-support.cc should be a Torque compiler output
rather than something that involves parsing C++ with regexes, but
this makes it correctly report subclass relationships for now.)
- The end offsets generated by Torque were off by one from the values
that would be generated by DEFINE_FIELD_OFFSET_CONSTANTS.
Change-Id: I3df4fcd27997b46c41ca879065b9d97f6c939f07
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1692192
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#62719}
RepresentationChanger::GetTaggedPointerRepresentation did not handle
kCompressed cases correctly for BigInts. This led to a crash of BigInt
benchmarks in js-perf-test.
Bug: v8:9407
Change-Id: Id1d60a81afc528c8d4180bd5de9d237f2f0abd0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701848
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62718}
This is a reland of a6eabacfee. We
decided that this feature needs more work.
Bug: v8:9088
Change-Id: I937f722e9356be5eca72cdf1edd552d132ee25be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701855
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62715}
This is a convenience flag to trace and debug invalidations. The
assumption used to be that protectors are rarely invalidated, but this
may happen more frequently than expected in practice.
Bug: v8:9463,v8:9466
Change-Id: Ice051593bda647070bc48d535edd03ba96c7dfcd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695469
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62714}
This reverts commit 060b9ec4a8, as the
issue has been resolved.
Bug: v8:7790
Change-Id: Id8a56ad50a508eacd191f2777cc5afc0b838364f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1700078
Commit-Queue: Georg Neis <neis@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62713}
The bytecode graph builder may insert additional jumps for the
SwitchOnGeneratorState bytecode and for loop headers. This plays into
what the graph builder considers dead/alive. We want the serializer to
process all the bytecodes that the graph builder will process, so the
serializer needs to do something similar.
Bug: v8:7790
Change-Id: I1f1d51f4a8951149e365b3c998cef7f613bb4953
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1647694
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62712}
When --concurrent-inlining is on, run bytecode analysis for all relevant
functions at serialization time, and store the results in the broker.
Change bytecode analysis such that running it for OSR produces information
that subsumes the non-OSR case. This lets us avoid doing and storing two
analyses for the top-level function in case we do OSR and the function
gets inlined into itself.
Bug: v8:7790
Change-Id: I7d5df0b2652e6e5c758c85578e51b4f8d041b0d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1690959
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62711}
When passing promises from other contexts to an `await`, the
--harmony-await-optimization doesn't kick in, and as such the
promise will be wrapped in a "native promise" (from this context).
That means the promises aren't chained immediately, but delayed
via a PromiseResolveThenableJob, which chains these promises on
the next turn of this contexts' microtask queue.
If there's anything happening on the macro task queue in between
this and the point when an exception is raised, the chaining will
have happened and we actually find our way back via the promise
chains. And this CL adds support for exactly that case. For other
cases, it's currently impossible to reconstruct the async stack
unfortunately, but we hope that this will help with the major
use cases, where the developer awaits on I/O.
Bug: v8:7522, v8:8673, v8:9487
Ref: nodejs/node#28680
Change-Id: Icc06c7df12644c2d8d43b6c7580ee06bb8f1024a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701847
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62709}
The object itself is already decompressed, and we're simply re-decompressing by
nuking the upper bits through sign extension.
Additionally this CL changes the branchless decompression sequence on x64 to be
cmov-based since that's shorter and faster. It's still slower than branchful
though, so we likely won't use it.
Change-Id: Ie6f9d38fb390b7300a236bf85d0db58d1ee959b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701842
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62708}
We had both jump slots and lazy compile slots in the same table. This
increases the space per slot to the maximum of the two, even though we
often do not use lazy compilation and could have smaller jump slots.
This CL splits the two into two separate tables. The lazy compile table
will only be created on demand, and will never be patched.
The jump table now only contains jumps, and is more compact (which
might improve performance because of improved locality).
R=mstarzinger@chromium.org
Bug: v8:9477
Change-Id: Ie182873a1ec612f71d1b54447021a9a8f8ca59db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698393
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62707}
... by making them const or converting them to pointers.
Bug: v8:9429
Change-Id: If4a7832944f5dc35cec04c11087499a552a7469a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1700073
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62705}
We never call GetTraceRecordMode() on the TraceConfig produced in D8
but instead always create the default ring buffer.
That means we ignore the "record_mode" argument supplied in config json
file.
Given we never use this we can remove the parsing code. The same thing
is true for enable_systrace and enable_argument_filter. All of these
are never used in V8 (they were copied from Chrome) but are part of the
public API so this CL just removes our parsing code for them but leaves
them in the API for now.
Bug: v8:8339
Change-Id: Iab5169536e20c19a784a55d013765125dd701773
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698397
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62704}
According to the specification, class-specific {operator new} and
{operator delete} should be static methods. Interestingly, if the
{static} keyword is missing, the methods are implicitly static anyway.
This is confusing, so this CL adds the {static} keywords explicitly.
It also removes the redundant {Malloced::New} and {Malloced::Delete}
methods.
R=mlippautz@chromium.org
Bug: v8:9396
Change-Id: I1db7c87b816567cc1a9153d0b18e3dd4ae81dd6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1700080
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62703}
This test no longer fails with concurrent inlining.
(Concurrent inlining is actually disabled in 'future' at the moment
but will be turned on again soon.)
Bug: v8:9094
Change-Id: I4d3f8021a7accff8cd670f3fef95a7995f1a9ba7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1700076
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62702}
This CL introduces new non-speculative operators BigIntAdd
and BigIntNegate. Instead of keeping speculative operators
until effect-control-linearization phase, they are now lowered
to non-speculative variants in the simplified lowering and
surrounded by the necessary checks. This adapts BigInt operators
to the common style of other operators (like Numbers).
Bug: v8:9407
Change-Id: I89ea7aef0d78c67b103971f8f63525b196ad3c0c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695467
Commit-Queue: Nico Hartmann <nicohartmann@google.com>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62699}
Problem description:
For prefixed WASM opcode, opcode prefix is printed as Unknown, not the opcode itself.
Take v128.load as an example:
before fix -> after fix
Unknown, 0x00, 0x04, 0x00, -> kExprS128LoadMem, 0x04, 0x00,
Change-Id: Id0cc5c723d19f60ad4f4f6c6ca338b5658c98c7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1694613
Commit-Queue: Jie Pan <jie.pan@intel.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62697}
