When enabled, this flag triggers a serialize-deserialize-verify pass
after script execution completes.
Bug: v8:10416
Change-Id: I377b8387762495eba07c807229fa464b00485bae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172426
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67527}
As per the all-hands a couple of weeks ago, the interpreter will
be removed soon. Remove running tests on this tier, so we no longer
put effort into maintaining tests for this tier.
Change-Id: I9fce0f3a7cd869d6ccecf1c1f820b794e89858e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2175021
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67520}
Any function with heap-allocated variables starts by creating and
pushing a new context for its execution. When entering the debugger due
to the stack check in the beginning of InterpreterEntryTrampoline, the
function has not yet had a chance to push that new context. The code in
ScopeIterator currently assumes that any function which needs a context
already has one by the time the debugger attempts to iterate scopes, but
in this case that assumption is invalid, which can cause a null deref.
This change introduces a new function ScopeIterator::NeedsAndHasContext
to replace previous calls to current_scope_->NeedsContext(). This new
function checks for the case where the current scope matches the closure
scope but the context matches the containing context for the function,
which implies that the function has not yet pushed its own context.
Bug: v8:10319, chromium:1038747
Change-Id: I29636f269c44d35b68d8446769d17170eed50e89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2168021
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67519}
ROL will be optional operator as arm, arm64 only have ROR.
The reason for this CL is inefficient Wasm codegen for 64-bit
left-rotation.
Bug: v8:10216
Change-Id: I0cd13e4b6de5276a0d0b80eac5ed9c2e52ba1f96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157648
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67518}
- Update opcode numbers, tests
- As the wasm-module-builder currently assumes opcode bytes, skip
the test that needs a multi-byte leb128 opcode
- Renumber post-MVP opcodes
Change-Id: I6531e954e63986dc6f7a3144ec054d16e6dc1b05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2173952
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67517}
Torque desugars try-catch/label constructs with several handlers
into nested try structures, with the first handler ending-up
innermost. So currently, if you write
try {
...
} label Foo {
Throw(...);
} catch (e) {
}
The catch will catch the preceding Throw in another handler.
This is different from how multiple try-catch handlers are done in
languages like Java, where throwing from a preceding catch handler
is not caught by a later one. To avoid this possible ambiguity, this
CL prohibits this pattern, enforcing that a catch handler comes first,
before any other label-handler attached to the same try.
This way, a catch handler never catches from any other handler on the
same try, since they have to come later.
Bug: v8:7793
Change-Id: I943f14b2393d307c4254a3fc3a78f236dbcf86df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2169098
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67516}
Formatter does not recognize #include, since we format .tq files as TS.
So replace it with a comment first, then substitute it back.
This should also fix the Presubmit in waterfall
https://ci.chromium.org/p/v8/builders/ci/V8%20Presubmit/10296
Change-Id: I316d52fc24e099474c542f75773683b54e8d0a63
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2175089
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67512}
This reverts commit fd2548f332.
Reason for revert: Breaks telemetry benchmark, blocks deps roll.
https://ci.chromium.org/p/chromium/builders/try/linux-rel/373686?
https://chromium-swarm.appspot.com/task?id=4be57eb0279bbb10
Original change's description:
> Reland^4 "[runtime] Amortize descriptor array growing for fast-mode prototypes"
>
> This CL:
> - stops tracking transitions for fast maps that are known to be detached
> - reuses descriptor arrays when transitioning detached maps to avoid O(n^2) performance and garbage creation
>
> Fix2 in reland: constructor_or_backpointer can be a smi since it can also hold a user-provided function.prototype
> Fix in reland: check whether the map of the back pointer is the metamap rather than reading the map of the constructor-or-backpointer slot. If the slot contains a constructor, it's possible that the object transitions while the concurrent marker is reading the map (from which it's reading the instance type); and it's possible that the transitioned map isn't set up yet fully when we read the instance type. An acquire load for the constructor-or-backpointer map would also fix it by serializing stores, but is more expensive. Checking the metamap is faster.
>
> Original commit message:
> > This avoids an O(n^2) algorithm that creates an equal amount of garbage.
> > Even though the actual final descriptor array might be a little bigger,
> > it reduces peak memory usage by allocating less.
>
> Change-Id: Id99dc76a369057e5c4d76a31163605cb38a66867
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172080
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67501}
TBR=ulan@chromium.org,verwaest@chromium.org
Change-Id: If305b5410ca37e04e9ec0ce50e9b494f5c4cd4dc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2174767
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67510}
Rolling v8/build: 26e9d48..d56e126
Rolling v8/buildtools: 7977eb1..204a35a
Rolling v8/buildtools/third_party/libunwind/trunk: 43bb9f8..d999d54
Rolling v8/third_party/aemu-linux-x64: 7YlCgase5GlIanqHn-nZClSlZ5kQETJyVUYRF7Jjy6UC..5G0SNnG7y5vrRx9uieYCXluC7lrENI134I3ts-s7BckC
Rolling v8/third_party/android_sdk/public: Jxtur3_L9RzY4q79K-AwIahwFW4oi5uYVD5URx9h62wC..zMVtBEihXp2Z0NYFNjLLmNrwy6252b_YWG6sh2l0QAcC
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/032c783..b0ad61f
Rolling v8/third_party/depot_tools: dd2f620..2072ffc
Rolling v8/third_party/fuchsia-sdk: 2457e41..277fe91
Rolling v8/third_party/jinja2: b41863e..3f90fa0
Rolling v8/third_party/zlib: 156be8c..21c6af6
Rolling v8/tools/clang: 105a846..b6a9eb3
Rolling v8/tools/swarming_client: 99e00d6..160b445TBR=machenbach@chromium.org,tmrts@chromium.org
Change-Id: I0a496658336c731c715a10d79c167e6159c48881
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2174543
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#67509}
I missed out the i8x16 implementation in https://crrev.com/c/2169017.
Bug: v8:9909
Change-Id: I3264e9dce51acca262ad71885379b320008555b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2173657
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67507}
31dabb56..6a18c27c
6a18c27 Generate test files from templates by Alexey Shvayka · 10 hours ago master
10a8c04 Test throw() called w/o arguments by Alexey Shvayka · 10 hours ago
75a0c1b Test return() called w/o arguments by Alexey Shvayka · 10 hours ago
4d9dccf Remove invalid feature, fix lint by Gus Caplan · 10 hours ago
850c653 Revert "Correct the expectation of zh-Hant" by Frank Yung-Fong Tang · 11 hours ago
fd90d58 Change `alphanum` to character class by Alexey Shvayka · 11 hours ago
d3b3e5e Make `alphanum` a non-capturing group by Alexey Shvayka · 11 hours ago
4371e3a Remove unnecessary capture group by Alexey Shvayka · 11 hours ago
af05e8e Revert "Simplify alphanum regex in testIntl.js" by Alexey Shvayka · 11 hours ago
a3c7d30 Add AsyncGeneratorFunction test by Alexey Shvayka · 3 days ago
69de665 Add GeneratorFunction test by Alexey Shvayka · 3 days ago
43bc9f1 Add Function test by Alexey Shvayka · 3 days ago
e8dfe54 Correct the expectation of zh-Hant by Frank Yung-Fong Tang · 4 days ago
76b3891 Correctly tag AggregateError proto-from-ctor-realm test by Shu-yu Guo · 4 days ago
c3e980a correct style-short.js by Frank Yung-Fong Tang · 4 days ago
df861e4 correct style-narrow.js by Frank Yung-Fong Tang · 4 days ago
d6c1b36 style-long.js by Frank Yung-Fong Tang · 4 days ago
17fe569 correct style-short.js by Frank Yung-Fong Tang · 4 days ago
81de828 correct style-narrow.js by Frank Yung-Fong Tang · 4 days ago
79c1818 Correct pl-pl*.js test for minimumGroupingDigits by Frank Yung-Fong Tang · 4 days ago
39ed5d9 Add object rest destructuring test by Alexey Shvayka · 4 days ago
b08380c Add object spread test by Alexey Shvayka · 4 days ago
c9ce3be Add Object.seal test by Alexey Shvayka · 4 days ago
feaa555 Add Object.isSealed test by Alexey Shvayka · 4 days ago
a65d0bf Add Object.isFrozen test by Alexey Shvayka · 4 days ago
521446b Add Object.freeze test by Alexey Shvayka · 4 days ago
07ff2ff Add Object.defineProperties test by Alexey Shvayka · 4 days ago
56cbc61 Add Object.getOwnPropertyDescriptors test by Alexey Shvayka · 4 days ago
2183fa7 Add Object.assign test by Alexey Shvayka · 4 days ago
0942fe1 correct comments by Frank Yung-Fong Tang · 4 days ago
9b54c22 correct comments by Frank Yung-Fong Tang · 4 days ago
aabf688 correct comment by Frank Yung-Fong Tang · 4 days ago
e72a965 Change the compareArray to allow new property by Frank Yung-Fong Tang · 4 days ago
21440c7 Change compareArray to allow new property by Frank Yung-Fong Tang · 4 days ago
fc55e45 Change the compareArray to allow new property by Frank Yung-Fong Tang · 4 days ago
8ad1225 Change compareArray to allow new property by Frank Yung-Fong Tang · 4 days ago
4fb0e70 add "fractionalSecondDigits" by Frank Yung-Fong Tang · 4 days ago
9c6ab18 Add fractionalSecondDigits by Frank Yung-Fong Tang · 4 days ago
Bug: v8:7834
Change-Id: If455a1d5b3629aba45060f97672ff829ce112fa8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2174068
Auto-Submit: Frank Tang <ftang@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67504}
This CL:
- stops tracking transitions for fast maps that are known to be detached
- reuses descriptor arrays when transitioning detached maps to avoid O(n^2) performance and garbage creation
Fix2 in reland: constructor_or_backpointer can be a smi since it can also hold a user-provided function.prototype
Fix in reland: check whether the map of the back pointer is the metamap rather than reading the map of the constructor-or-backpointer slot. If the slot contains a constructor, it's possible that the object transitions while the concurrent marker is reading the map (from which it's reading the instance type); and it's possible that the transitioned map isn't set up yet fully when we read the instance type. An acquire load for the constructor-or-backpointer map would also fix it by serializing stores, but is more expensive. Checking the metamap is faster.
Original commit message:
> This avoids an O(n^2) algorithm that creates an equal amount of garbage.
> Even though the actual final descriptor array might be a little bigger,
> it reduces peak memory usage by allocating less.
Change-Id: Id99dc76a369057e5c4d76a31163605cb38a66867
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172080
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67501}
This reverts commit 656308502e.
Reason for revert: due to failures
Original change's description:
> Reland^3 "[runtime] Amortize descriptor array growing for fast-mode prototypes"
>
> This CL:
> - stops tracking transitions for fast maps that are known to be detached
> - reuses descriptor arrays when transitioning detached maps to avoid O(n^2) performance and garbage creation
>
> Fix in reland: check whether the map of the back pointer is the metamap rather than reading the map of the constructor-or-backpointer slot. If the slot contains a constructor, it's possible that the object transitions while the concurrent marker is reading the map (from which it's reading the instance type); and it's possible that the transitioned map isn't set up yet fully when we read the instance type. An acquire load for the constructor-or-backpointer map would also fix it by serializing stores, but is more expensive. Checking the metamap is faster.
>
> Original commit message:
> > This avoids an O(n^2) algorithm that creates an equal amount of garbage.
> > Even though the actual final descriptor array might be a little bigger,
> > it reduces peak memory usage by allocating less.
>
> TBR=ulan@chromium.org,ishell@chromium.org
>
> Change-Id: I57000949debdee2b69dd41e0c5975b3e8a34c6f4
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: b:148346655, v8:10339
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2173363
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67499}
TBR=ulan@chromium.org,clemensb@chromium.org,ishell@chromium.org,verwaest@chromium.org
Change-Id: Ie7018912f591d397c8acede9b31fbf269d225fe4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: b:148346655, v8:10339
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2174299
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67500}
This CL:
- stops tracking transitions for fast maps that are known to be detached
- reuses descriptor arrays when transitioning detached maps to avoid O(n^2) performance and garbage creation
Fix in reland: check whether the map of the back pointer is the metamap rather than reading the map of the constructor-or-backpointer slot. If the slot contains a constructor, it's possible that the object transitions while the concurrent marker is reading the map (from which it's reading the instance type); and it's possible that the transitioned map isn't set up yet fully when we read the instance type. An acquire load for the constructor-or-backpointer map would also fix it by serializing stores, but is more expensive. Checking the metamap is faster.
Original commit message:
> This avoids an O(n^2) algorithm that creates an equal amount of garbage.
> Even though the actual final descriptor array might be a little bigger,
> it reduces peak memory usage by allocating less.
TBR=ulan@chromium.org,ishell@chromium.org
Change-Id: I57000949debdee2b69dd41e0c5975b3e8a34c6f4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: b:148346655, v8:10339
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2173363
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67499}
Forced GCs can either be invoked internally or communicate the fact that
they are forced externally via API. Before this CL, all uses were
passing kGCCallbackFlagForced to indicate that the GC was forced.
This flag is used by embedders though to trigger followup actions. E.g.,
it can be used to trigger a follow up call to
GarbageCollectionForTesting() call which requires --expose-gc.
This patch changes the semantics as follows:
- Internal forced GCs use a Heap GC flag (kForcedGC)
- External forced GCs and GC extension use kGCCallbackFlagForced
Bug: chromium:1074061
Change-Id: Ide7ea0ccdf88b8c8cac002289aef5b7eb0f9748c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172747
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67498}
This reverts commit d29b2f815b.
Reason for revert: accidental reland without fix
Original change's description:
> Reland^2 "[runtime] Amortize descriptor array growing for fast-mode prototypes"
>
> Fix: check whether the map of the back pointer is the metamap rather than reading the map of the constructor-or-backpointer slot. If the slot contains a constructor, it's possible that the object transitions while the concurrent marker is reading the map (from which it's reading the instance type); and it's possible that the transitioned map isn't set up yet fully when we read the instance type. An acquire load for the constructor-or-backpointer map would also fix it by serializing stores, but is more expensive. Checking the metamap is faster.
>
> In case of false negatives (it is a map but we read the field before it was properly initialized) we'll simply mark too many descriptors in the worst case.
>
> Original change's description:
> > Revert "Reland "[runtime] Amortize descriptor array growing for fast-mode prototypes""
> >
> > This reverts commit 71f9c1179a.
> >
> > Reason for revert: Seems to cause several TSan flakes, e.g. https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20concurrent%20marking/12926
> >
> > Original change's description:
> > > Reland "[runtime] Amortize descriptor array growing for fast-mode prototypes"
> > >
> > > This is a reland of 2de2d3dcdc
> > >
> > > Original change's description:
> > > > [runtime] Amortize descriptor array growing for fast-mode prototypes
> > > >
> > > > This avoids an O(n^2) algorithm that creates an equal amount of garbage.
> > > > Even though the actual final descriptor array might be a little bigger,
> > > > it reduces peak memory usage by allocating less.
> > > >
> > > > Bug: b:148346655
> > > > Change-Id: I984159d36e9e0b37c19bc81afc90c94c9a9d168a
> > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135728
> > > > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> > > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
> > > > Cr-Commit-Position: refs/heads/master@{#67031}
> > >
> > > Bug: b:148346655, v8:10339
> > > Change-Id: I24436d8f49dc1fe527c4f6558db1abcba323b6f8
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2139215
> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
> > > Auto-Submit: Toon Verwaest <verwaest@chromium.org>
> > > Commit-Queue: Igor Sheludko <ishell@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#67475}
> >
> > TBR=ulan@chromium.org,ishell@chromium.org,verwaest@chromium.org
> >
> > Change-Id: I6fa02d0c89557eae33b792c1fe62c9c15eb0f7c7
> > No-Presubmit: true
> > No-Tree-Checks: true
> > No-Try: true
> > Bug: b:148346655, v8:10339
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172749
> > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > Commit-Queue: Clemens Backes <clemensb@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#67478}
>
> TBR=ulan@chromium.org,clemensb@chromium.org,ishell@chromium.org,verwaest@chromium.org
>
> Change-Id: Ib86e039374e721919cd5b02495c252ee7af283bd
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: b:148346655, v8:10339
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2173359
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67495}
TBR=ulan@chromium.org,clemensb@chromium.org,ishell@chromium.org,verwaest@chromium.org
Change-Id: Ia624ac774c021146b9b3b7e60372113c50a1ec61
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: b:148346655, v8:10339
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2173361
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67497}
When a background thread fails to allocate, it requests a GC and
retries the allocation afterwards. Make second allocation more likely
to succeed by allowing those allocations to expand the old space.
TLABs of LocalHeaps also need to be invalidated before the GC.
Bug: v8:10315
Change-Id: Idaea2c4ee25642d508c72ae274b06d60c6e225e0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154193
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67496}
Fix: check whether the map of the back pointer is the metamap rather than reading the map of the constructor-or-backpointer slot. If the slot contains a constructor, it's possible that the object transitions while the concurrent marker is reading the map (from which it's reading the instance type); and it's possible that the transitioned map isn't set up yet fully when we read the instance type. An acquire load for the constructor-or-backpointer map would also fix it by serializing stores, but is more expensive. Checking the metamap is faster.
In case of false negatives (it is a map but we read the field before it was properly initialized) we'll simply mark too many descriptors in the worst case.
Original change's description:
> Revert "Reland "[runtime] Amortize descriptor array growing for fast-mode prototypes""
>
> This reverts commit 71f9c1179a.
>
> Reason for revert: Seems to cause several TSan flakes, e.g. https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20concurrent%20marking/12926
>
> Original change's description:
> > Reland "[runtime] Amortize descriptor array growing for fast-mode prototypes"
> >
> > This is a reland of 2de2d3dcdc
> >
> > Original change's description:
> > > [runtime] Amortize descriptor array growing for fast-mode prototypes
> > >
> > > This avoids an O(n^2) algorithm that creates an equal amount of garbage.
> > > Even though the actual final descriptor array might be a little bigger,
> > > it reduces peak memory usage by allocating less.
> > >
> > > Bug: b:148346655
> > > Change-Id: I984159d36e9e0b37c19bc81afc90c94c9a9d168a
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135728
> > > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#67031}
> >
> > Bug: b:148346655, v8:10339
> > Change-Id: I24436d8f49dc1fe527c4f6558db1abcba323b6f8
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2139215
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Igor Sheludko <ishell@chromium.org>
> > Auto-Submit: Toon Verwaest <verwaest@chromium.org>
> > Commit-Queue: Igor Sheludko <ishell@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#67475}
>
> TBR=ulan@chromium.org,ishell@chromium.org,verwaest@chromium.org
>
> Change-Id: I6fa02d0c89557eae33b792c1fe62c9c15eb0f7c7
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: b:148346655, v8:10339
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172749
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67478}
TBR=ulan@chromium.org,clemensb@chromium.org,ishell@chromium.org,verwaest@chromium.org
Change-Id: Ib86e039374e721919cd5b02495c252ee7af283bd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: b:148346655, v8:10339
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2173359
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67495}
Spilling a register in Liftoff require a scratch register when the
offset of the stack slot from fp is greater than 2^12. This CL adds
a check to LiftoffAssembler::Spill on arm to check that a scratch
register is available. It also fixes one case where the scratch register
was not available.
R=clemensb@chromium.orgCC=zhin@chromium.org
Bug: chromium:1075953
Change-Id: Idb2bc7e26e3d4fbd6bb0eb6c9a9b8cfd8b3c569e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172424
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67494}
Rolling to chrome/src is in
https://chromium-review.googlesource.com/c/chromium/src/+/2155530
Since auto rolling stop after 3/24/2020 and the rolling will cause
change of test status, I get this cl ready (but not running trybot due
to 1074260) and plan to hand roll after the submission of 2155530.
Bug: chromium:1064326, v8:9515, v8:10379, v8:10380, v8:10437
Change-Id: I19554f68cfdc5b717dfc7fc4b1222e9dc25b8d69
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2158486
Auto-Submit: Frank Tang <ftang@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67493}
The interpreter will be un-shipped soon, hence we cannot have a
compilation hint for interpreted execution.
This CL removes the respective enum value, removes a test which
specifically tested this one option, and adapts other code to use one of
the remaining hints.
R=ahaas@chromium.org
Bug: v8:10389
Change-Id: Ia754f7de95be271000a9e4e10ef2a3ee171da627
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172748
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67491}
Supporting WebAssembly evaluator modules requires support for passing
binary data as a parameter to CDP methods. Currently, the required base64
conversions are not implemented.
Bug: chromium:1020120
Change-Id: Ie74f93ee5accfa369aac428e5c5b5f882c921c52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2152645
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67490}
The UnicodePropertyEscapeCodeSize test set the max code size as 150KB,
which is too strict for mips64. This CL loosen the limit to 200KB.
Bug: v8:10441
Change-Id: I8532d4d51eedd7713075d86e84c52a58d2412861
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172927
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Cr-Commit-Position: refs/heads/master@{#67489}
Previously, we fixed the decoding of SIMD opcodes >= 0x80 that reads an
immediate. However, we left behind a TODO for SIMD opcodes <= 0x80. This
fixes it.
Given a byte sequence such as [0xfd, 0x80, 0x80, 0x0], it decodes to the
SIMD opcode S128LoadMem (the last 3 bytes decode to 0, it is not the
most efficient encoding, but is still valid). Then, when we are decoding
the immediate memarg that follows this, we need to skip ahead 3 bytes
(opcode_length). We were not doing that previously.
This patch changes the signature of SimdLaneImmediate and
Simd8x16ShuffleImmediate to make this requirement clearer. It takes a
new argument opcode_length, which is the number of bytes the LEB encoded
opcode takes up. The pc should then be passed in unchanged.
In function-body-decoder-impl.h, we also consistently pass down
opcode_length into the various helpers, and use that value to decode
immediates.
Changes have been made to wasm-interpreter to record the opcode_length
to be passed down to helpers.
Bug: chromium:1075719
Bug: v8:10258
Change-Id: I502c9ef47d4da2abadf14218bf0da19b291ec55c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2171460
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67483}
Tweak the register allocation logic in liftoff-compiler.cc. If we reuse
src1 or src2 for dst, it complicates the logic in the codegen
significantly. We will need to check which operand dst is equals to,
back it up, then make sure the mask ends up in dst (since thats how vbsl
and bsl works, the first operand holds the mask and is overwritten). By
tweaking the allocation logic, no code gen is required for the other
backends.
Bug: v8:9909
Change-Id: I17843322508b18247c91e5959cf1b996b7f6a61d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2171468
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67481}
This reverts commit 908f08e43f.
Reason for revert: Seems like it may be causing v8-fuzzer failures: https://ci.chromium.org/p/v8/builders/ci/V8%20Fuzzer/36017
Original change's description:
> [ast] Remove literal allocation from CallPrinter
>
> Access literal data directly in CallPrinter, rather than allocating
> their values. This allows us to remove the isolate member from
> CallPrinter entirely.
>
> Change-Id: Ib4203009c86b6778ee843e8956fc7cee2214841e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122019
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67471}
TBR=leszeks@chromium.org,verwaest@chromium.org
Change-Id: Ia7e0c95ee6ec58e5067d92c7517269fd334041a1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2171929
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67480}
