This also disables the test on tsan bots and on bots that have
dchecks always enabled, which includes try bots.
Bug: v8:8332, v8:8831
Change-Id: Ib52cd32985d50e89ddfdc525f08f60ddfd981f1e
Reviewed-on: https://chromium-review.googlesource.com/c/1297319
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57000}
The "max_len" argument for fuzzer targets is deprecated. We need to
enforce the limit internally.
R=ahaas@chromium.org
Bug: chromium:894939
Change-Id: I2206bc63d5e39f1aa189e11042a6a0bbcca31b0d
Reviewed-on: https://chromium-review.googlesource.com/c/1299020
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56998}
This adds support for having reference type values (i.e. anyref) stored
in an exception. It is the natural combination of the reference type
proposal and the exception handling proposal.
Note that this also introduces support for having write barriers in
generated WasmCode, as this is the first time we are storing references
within generated code. Such write barriers will be needed for other uses
of reference types (e.g. mutable global) regardless.
R=clemensh@chromium.org
TEST=mjsunit/wasm/exceptions-anyref
BUG=v8:8341
Change-Id: I1211d4a850954622cb873eede0b4024fecc3dd8b
Reviewed-on: https://chromium-review.googlesource.com/c/1296484
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56995}
The {CompilationState} currently stores the {WasmEngine}, while the
{NativeModule} only stores the {WasmCodeManager}. From a high-level
view, this does not make much sense. The {NativeModule} belongs to
exactly one {WasmEngine}, so that link should be stored there. We can
then get to the {WasmCodeManager} from the {WasmEngine}.
This change requires a refactoring of the {WasmCodeManagerTest} which
created {WasmCodeManager}s independent of the {Isolate} and the
{WasmEngine}. This is not supported any more.
Note that in production, each {WasmEngine} owns exactly one
{WasmCodeManager} and one {WasmMemoryTracker}, so testing that a
{WasmMemoryTracker} can be shared by several {WasmCodeManager}s didn't
make sense in the first place.
R=mstarzinger@chromium.org
Bug: v8:8217
Change-Id: I582e698be35f97dbd38bf6e12eb7f8ee4fc1f0f2
Reviewed-on: https://chromium-review.googlesource.com/c/1297960
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56992}
This CL allows ExtractFixedArray to know if the JSArray has only Smi
elements. In that case ExtractFixedArray will always skip write barriers
when copying the Smi-only backing store. In the case that the copying
is not possibly conflicting with the concurrent marker, CopyElements will
efficiently use memcpy for further performance.
This improves the performance of ExtractFastJSArray and CloneFastJSArray.
As a result, performance of copying Smi arrays by slice() and spreading is
improved, except for spreading Smi holey arrays.
Bug: v8:7980
Change-Id: Ie39f8abf3b5039cc12a8ca7ece81352375e0e9da
Reviewed-on: https://chromium-review.googlesource.com/c/1286340
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Hai Dang <dhai@google.com>
Cr-Commit-Position: refs/heads/master@{#56989}
This is a reland of a31a623047
Original change's description:
> [ia32] Remove poisoning logic on ia32
>
> Poisoning has been disabled by default on ia32 a while ago. This CL
> removes its logic from ia32 code generation, which will let us move
> towards fuller (and unconditional) root register support.
>
> Bug: chromium:860429, v8:8254
> Change-Id: I8f672cf48a6ffc7bf21e7794c1b7463d7f8b9594
> Reviewed-on: https://chromium-review.googlesource.com/c/1296131
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56978}
Tbr: mstarzinger@chromium.org,jarin@chromium.org
Bug: chromium:860429, v8:8254
Change-Id: Ia65ac57fdc6b9a0f59cc64455d6a000005e9be3b
Reviewed-on: https://chromium-review.googlesource.com/c/1299080
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56984}
PrepareElementsForSort must return a number less than or equal the array
length.
Bug: chromium:897512, v8:7382
Change-Id: If5f9c4d052e623ab9f3300b8534603abbee859fa
Reviewed-on: https://chromium-review.googlesource.com/c/1297958
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56982}
Resets the isolate's context to nullptr in debug builds during bytecode finalization
to ensure that we don't rely on the native context during context independent
unoptimized compilation.
BUG=chromium:898076, v8:8041
Change-Id: Ifaa5006a7a3d31d7fbd535ebb63f8889c75526c4
Reviewed-on: https://chromium-review.googlesource.com/c/1297961
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56979}
This is a reland of fcbb023b0e
Original change's description:
> Add Windows ARM64 ABI support to V8
>
> This change added Windows ARM64 ABI support, major things are:
> 1. Excluding x18 register from any usage because it is reserved as
> platform register. Preserve alignment after the change.
> 2. Fix the assumption of LP64 in arm64 backend. Windows ARM64 is
> still LLP64.
> 3. Stack guard page probe for large allocation on stack.
>
> Reference:
> Windows ARM64 ABI:
> https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2017
>
> Bug: chromium:893460
> Change-Id: I325884ac8dab719154a0047141e18a9fcb8dff7e
> Reviewed-on: https://chromium-review.googlesource.com/c/1285129
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56881}
CQ_INCLUDE_TRYBOTS=luci.chromium.try:android_arm64_dbg_recipe
TBR=mlippautz@chromium.org
Bug: chromium:893460
Change-Id: Icc45fd091c33f7df805842a70236b79b14756f52
Reviewed-on: https://chromium-review.googlesource.com/c/1297300
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56965}
Add position to the return of %SegmentIterator%.next()
which newly added to the spec in
https://github.com/tc39/proposal-intl-segmenter/pull/42
Bug: v8:8305
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I8de7102acb670a6c529ab3e35601c78a8dc7703c
Reviewed-on: https://chromium-review.googlesource.com/c/1278636
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56963}
Remove TODO that is already done
Uncomment two working tests.
Bug: v8:5751
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Icb28d84e92812996c2928e90961d75508ba4c401
Reviewed-on: https://chromium-review.googlesource.com/c/1296933
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56961}
BuildClassBoilerplate accessed the native context to get the
class_function_descriptors. Baseline compilation should be native context
independent, so we shouldn't access the native context at all. As it happens,
class_function_descriptors wasn't used so can just be removed.
BUG=chromium:898076, v8:8041
Change-Id: If9c0edf3dfde68c76ea87820f9d4b080aac6d60e
Reviewed-on: https://chromium-review.googlesource.com/c/1298033
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56958}
This changes the ReceiverOrOddball feedback on JSStrictEqual to
ReceiverOrNullOrUndefined feedback, which can also safely be
consumed by JSEqual (we cannot generally accept any oddball here
since booleans trigger implicit conversions, unfortunately).
Thus we replace the previously introduced CheckReceiverOrOddball
with CheckReceiverOrNullOrUndefined, and drop CheckOddball, since
we will no longer collect Oddball feedback separately.
TurboFan will then turn a JSEqual[ReceiverOrNullOrUndefined] into
a sequence like this:
```
left = CheckReceiverOrNullOrUndefined(left);
right = CheckReceiverOrNullOrUndefined(right);
result = if ObjectIsUndetectable(left) then
ObjectIsUndetectable(right)
else
ReferenceEqual(left, right);
```
This significantly improves the peak performance of abstract equality
with Receiver, Null or Undefined inputs. On the test case outlined in
http://crbug.com/v8/8356 we go from
naive: 2946 ms.
tenary: 2134 ms.
to
naive: 2230 ms.
tenary: 2250 ms.
which corresponds to a 25% improvement on the abstract equality case.
For regular code this will probably yield more performance, since we
get rid of the JSEqual operator, which might have arbitrary side
effects and thus blocks all kinds of TurboFan optimizations. The
JSStrictEqual case is slightly slower now, since it has to rule out
booleans as well (even though that's not strictly necessary, but
consistency is key here).
This way developers can safely use `a == b` instead of doing a dance
like `a == null ? b == null : a === b` (which is what dart2js does
right now) when both `a` and `b` are known to be Receiver, Null or
Undefined. The abstract equality is not only faster to parse than
the tenary, but also generates a shorter bytecode sequence. In the
test case referenced in http://crbug.com/v8/8356 the bytecode for
`naive` is
```
StackCheck
Ldar a1
TestEqual a0, [0]
JumpIfFalse [5]
LdaSmi [1]
Return
LdaSmi [2]
Return
```
which is 14 bytes, whereas the `tenary` function generates
```
StackCheck
Ldar a0
TestUndetectable
JumpIfFalse [7]
Ldar a1
TestUndetectable
Jump [7]
Ldar a1
TestEqualStrict a0, [0]
JumpIfToBooleanFalse [5]
LdaSmi [1]
Return
LdaSmi [2]
Return
```
which is 24 bytes. So the `naive` version is 40% smaller and requires
fewer bytecode dispatches.
Bug: chromium:898455, v8:8356
Change-Id: If3961b2518b4438700706b3bd6071d546305e233
Reviewed-on: https://chromium-review.googlesource.com/c/1297315
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56948}
This is a reland of ec969ea3b1
Temporarily removes high memory usage test.
Original change's description:
> [builtins] Fix Array.p.join length overflow and invalid string length handling
>
> - Fixes and simplify allocating the temporary fixed array for ToString-ed elements.
> - When the array size is greater than representable by an intptr, it overflowed into a negative value causing a non-negative assert to fail.
> - Simplify fallback behavior by always allocating a conservatively sized temporary fixed array. Previously, if the array had dictionary elements, the temporary fixed array was sized based on %GetNumberDictionaryNumberOfElements() and then resized when entering the fallback.
>
> - Fixes related invalid string length handling. When the running total of the resulting string length overflowed or exceeded String::kMaxLength, a RangeError is thrown. Previously, this thrown RangeError bypassed JoinStackPop and left the receiver on the stack.
>
> Bug: chromium:897404
> Change-Id: I157b71ef04ab06125a5b1c3454e5ed3713bdb591
> Reviewed-on: https://chromium-review.googlesource.com/c/1293070
> Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56907}
Bug: chromium:897404
Change-Id: I4995893f6f9724b26c231d05619ad65dbccc7223
Reviewed-on: https://chromium-review.googlesource.com/c/1297675
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#56946}
Previously StringToList use the length of the original string, which is
not the right value: we expect the length of the new array to be the
number of characters (codepoints).
Bug: v8:7980
Change-Id: I2efca5715323c4399cb45c53871ae349207f3458
Reviewed-on: https://chromium-review.googlesource.com/c/1297320
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56944}
Because of ordering issues we didn't set the wire bytes on the
{NativeModule} during {OnFinishedStream}. We then failed during
instantiation when trying to read the import names from the wire bytes.
This CL fixes this locally without much code churn. I plan to clean up
the interaction between {AsyncCompileJob} and {AsyncStreamingProcessor}
in a follow-up CL.
R=ahaas@chromium.org
Bug: chromium:898310
Change-Id: I06337a04ba380f87b803f325323208298d363f41
Reviewed-on: https://chromium-review.googlesource.com/c/1296467
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56938}
This was fixed when introducing the IR.
Bug: v8:8216
Change-Id: Iebb212a2c21499b1738832457b660038e3a48975
Reviewed-on: https://chromium-review.googlesource.com/c/1297313
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56931}
This CL introduces proper Oddball and ReceiverOrOddball states for the
CompareOperationFeedback, and updates the StrictEqual IC to collect this
feedback as well. Previously it would not collect Oddball feedback, not
even in the sense of NumberOrOddball, since that's not usable for the
SpeculativeNumberEqual.
The new feedback is handled via newly introduced CheckReceiverOrOddball
and CheckOddball operators in TurboFan, introduced by JSTypedLowering.
Just like with the Receiver feedback, it's enough to check one side and
do a ReferenceEqual afterwards, since strict equal can only yield true
if both sides refer to the same instance.
This improves the benchmark mentioned in http://crbug.com/v8/8356 from
naive: 2950 ms.
tenary: 2456 ms.
to around
naive: 2996 ms.
tenary: 2192 ms.
which corresponds to a roughly 10% improvement in the case for the
tenary pattern, which is currently used by dart2js. In real world
scenarios this will probably help even more, since TurboFan is able
to optimize across the strict equality, i.e. there's no longer a stub
call forcibly spilling all registers that are live across the call.
This new feedback will be used as a basis for the JSEqual support for
ReceiverOrOddball, which will allow dart2js switching to the shorter
a==b form, at the same peak performance.
Bug: v8:8356
Change-Id: Iafbf5d64fcc9312f9e575b54c32c631ce9b572b2
Reviewed-on: https://chromium-review.googlesource.com/c/1297309
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56925}
Remove ICUService and decentralize GetAvailableLocales to each class.
Refactor part of the Intl::GetAvailableLocales into Intl::BuildLocaleSet
as helper function.
Bug: v8:5751
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ic82d919cbf7ec840a7df3b0fa040561534c105a1
Reviewed-on: https://chromium-review.googlesource.com/c/1295934
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56923}
as part of the continuing quest to get rid of Object*/Object**.
This is a fairly mechanical replacement of Object**/MaybeObject** with
wrapper objects carrying the same data. No change in behavior is intended.
Overloaded operators are provided to minimize code churn.
Bug: v8:3770
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I76cee82b8bf2dd80a1b66f09dd2bb2b65038eeb7
Reviewed-on: https://chromium-review.googlesource.com/c/1287889
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56920}
The assertion was intended to verify that the function is only called
at appropriate times (at a point when it was called both by by other builtins, and by desugarings added in the parser and during bytecode generation) --- However, it didn't account for the case where
the wrapper Promise is resolved with another JSPromise with a
non-callable "then" method. (Step 12 of
https://tc39.github.io/ecma262/#sec-promise-resolve-functions):
"If IsCallable(thenAction) is false, then
Return FulfillPromise(promise, resolution)."
It would be observable to verify this behaviour by loading the "then"
value and asserting that it's non-callable, so instead the CSA_ASSERT
is just removed and replaced with a comment explaining the appropriate
use of the function.
BUG=chromium:897436, v8:5855
R=bmeurer@chromium.org
Change-Id: Ib4b11abfe3339409b57ccfda9c3f75a34e0db532
Reviewed-on: https://chromium-review.googlesource.com/c/1296909
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56916}
This reverts commit ec969ea3b1.
Reason for revert: test fails consistently on arm bots.
I can't repro the failure locally, but it does consume ~512MB of memory (for a single string, I think?), so my guess is that the bots don't have enough contiguous address space.
Original change's description:
> [builtins] Fix Array.p.join length overflow and invalid string length handling
>
> - Fixes and simplify allocating the temporary fixed array for ToString-ed elements.
> - When the array size is greater than representable by an intptr, it overflowed into a negative value causing a non-negative assert to fail.
> - Simplify fallback behavior by always allocating a conservatively sized temporary fixed array. Previously, if the array had dictionary elements, the temporary fixed array was sized based on %GetNumberDictionaryNumberOfElements() and then resized when entering the fallback.
>
> - Fixes related invalid string length handling. When the running total of the resulting string length overflowed or exceeded String::kMaxLength, a RangeError is thrown. Previously, this thrown RangeError bypassed JoinStackPop and left the receiver on the stack.
>
> Bug: chromium:897404
> Change-Id: I157b71ef04ab06125a5b1c3454e5ed3713bdb591
> Reviewed-on: https://chromium-review.googlesource.com/c/1293070
> Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56907}
TBR=danno@chromium.org,peter.wm.wong@gmail.com,jgruber@chromium.org,tebbi@chromium.org
Change-Id: I8ca80bd75833aacc94ccb25ceb82bbc8880991db
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:897404
Reviewed-on: https://chromium-review.googlesource.com/c/1297471
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56915}
This reverts commit fcbb023b0e.
Reason for revert: blocks roll https://chromium-review.googlesource.com/c/chromium/src/+/1296315
Original change's description:
> Add Windows ARM64 ABI support to V8
>
> This change added Windows ARM64 ABI support, major things are:
> 1. Excluding x18 register from any usage because it is reserved as
> platform register. Preserve alignment after the change.
> 2. Fix the assumption of LP64 in arm64 backend. Windows ARM64 is
> still LLP64.
> 3. Stack guard page probe for large allocation on stack.
>
> Reference:
> Windows ARM64 ABI:
> https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2017
>
> Bug: chromium:893460
> Change-Id: I325884ac8dab719154a0047141e18a9fcb8dff7e
> Reviewed-on: https://chromium-review.googlesource.com/c/1285129
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56881}
TBR=bbudge@chromium.org,ulan@chromium.org,machenbach@chromium.org,hpayer@chromium.org,brucedawson@chromium.org,mlippautz@chromium.org,ahaas@chromium.org,bmeurer@chromium.org,Tom.Tan@microsoft.com
Change-Id: I0b804af6dfca9409a655194fa6e5407f209be2dc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:893460
Reviewed-on: https://chromium-review.googlesource.com/c/1296460
Reviewed-by: Michael Hablich <hablich@chromium.org>
Commit-Queue: Michael Hablich <hablich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56912}
- Fixes and simplify allocating the temporary fixed array for ToString-ed elements.
- When the array size is greater than representable by an intptr, it overflowed into a negative value causing a non-negative assert to fail.
- Simplify fallback behavior by always allocating a conservatively sized temporary fixed array. Previously, if the array had dictionary elements, the temporary fixed array was sized based on %GetNumberDictionaryNumberOfElements() and then resized when entering the fallback.
- Fixes related invalid string length handling. When the running total of the resulting string length overflowed or exceeded String::kMaxLength, a RangeError is thrown. Previously, this thrown RangeError bypassed JoinStackPop and left the receiver on the stack.
Bug: chromium:897404
Change-Id: I157b71ef04ab06125a5b1c3454e5ed3713bdb591
Reviewed-on: https://chromium-review.googlesource.com/c/1293070
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56907}
Whenever left-trimming is possible (e.g. whenever user code is
called), we must not store a reference to an exposed JSArray's
elements.
Bug: chromium:897366,v8:7382
Change-Id: I8dd6a93aa6ed19e755ccce7122e0e019dc578a31
Reviewed-on: https://chromium-review.googlesource.com/c/1292066
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56903}
Instead, create it when needed and pass it down to the actual
compilation.
This saves memory by making the WasmCompilationUnit smaller and will
eventually allow us to implement the trap handler fallback correctly by
using an updated ModuleEnv in background compilation and tier up.
R=mstarzinger@chromium.org
Bug: v8:5277, v8:8343
Change-Id: I0dc3a37fb88e54eb4822dc99d58ff024f4b2a367
Reviewed-on: https://chromium-review.googlesource.com/c/1293953
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56896}
This is to fix test262 tests which expect that there is no arguments
object.
Bug: v8:7186
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I56205c29609666dc832297e4d36a4d487eae36cc
Reviewed-on: https://chromium-review.googlesource.com/c/1291469
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56890}
Previously we'd first accumulate errors to the parent and validate the
destructuring pattern in the parent. In the case of ParseArguments this
will invalidly propagate binding pattern errors from one argument to the
next. The reason why ParseArguments keeps track of binding pattern errors
is because it could also be used to parse async arrow function parameters.
If we see async(a,b) we don't yet know whether this is the head of an
async arrow function, or a call to async with arguments a and b.
Bug: v8:8241
Change-Id: I670ab9a9c6f2e0bee399808b02a465ae1afa7c3f
Reviewed-on: https://chromium-review.googlesource.com/c/1296229
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56887}
In the ElementsAccessor fast-path for Array.prototype.includes, we
iterate backing-store elements according to start and length numbers
which might or might not be within the JSArray::length field, for
example when side-effects changed the receiver while start and length
are computed. So even when we have a packed ElementsKind, we might still
observe the hole. This is fine, since logical out-of-bounds accesses
are safe in this case, but it means we must not rely on the
ElementsKind telling us if we can encounter holes.
Bug: chromium:897098
Change-Id: I17db38246aef6edbdd5cee30598cbf7619aba6d8
Reviewed-on: https://chromium-review.googlesource.com/c/1293571
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56884}
The DEPS file was already up to date, so we only had to update the hash.
R=herhut@chromium.org
Change-Id: Ibbf960e140746b522339cb8f649691a08f4cd485
Reviewed-on: https://chromium-review.googlesource.com/c/1293576
Reviewed-by: Stephan Herhut <herhut@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56883}
This change added Windows ARM64 ABI support, major things are:
1. Excluding x18 register from any usage because it is reserved as
platform register. Preserve alignment after the change.
2. Fix the assumption of LP64 in arm64 backend. Windows ARM64 is
still LLP64.
3. Stack guard page probe for large allocation on stack.
Reference:
Windows ARM64 ABI:
https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2017
Bug: chromium:893460
Change-Id: I325884ac8dab719154a0047141e18a9fcb8dff7e
Reviewed-on: https://chromium-review.googlesource.com/c/1285129
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56881}
This CL replaces the stack trace parameter with a the array that is
usually passed to the JS prepareStackTrace callback. This allows two
important goals to be realized: 1) we can easily stringify individual
frames and 2) we can (if needed) call back into JS from this callback
with a usable structure. If, as is sometimes the case, a v8::StackTrace
is needed, |v8::Exception::GetStackTrace| can be used on the exception
that is passed to PrepareStackTraceCallback.
Bug: v8:7637
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I57fa1f2b4552cc7f69351fe0918f4e59e3f5fce1
Reviewed-on: https://chromium-review.googlesource.com/c/1266698
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56880}
Fold methods from intl.* to objects/intl-objects.*
Move Isolate* to the first parameter for some method
Move ICUSerice type under Intl
Hide ICUTimeZoneCache under a CreateTimeZoneCache factory method.
Bug: v8:5751
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ie6f6a1ceee789333a077c1965de8e11d8c15c175
Reviewed-on: https://chromium-review.googlesource.com/c/1293109
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56873}
Full custom preview generation is moved to custom-preview file
including frontend part. New custom preview implementation returns
body getter function instead of bind function, formatter and config
objects. Body getter function calls formatter.body(object, config)
and returns json ML.
R=dgozman@chromium.org
Bug: chromium:595206
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I14ff3d8abb4a47d2bbc2e6eaa1835fc362ac7369
Reviewed-on: https://chromium-review.googlesource.com/c/1292686
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56872}
TryLookupCode can be passed arbitrary addresses, e.g. by tentative
name lookups during disassembly. This CL makes sure that addresses
within non-builtin-code sections of the embedded blob (metadata or
padding) are handled properly.
Bug: v8:6666, v8:8334
Change-Id: I42eca57062e30eabd7bb1b069786aa809706cd2c
Reviewed-on: https://chromium-review.googlesource.com/c/1292060
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56865}
