This reverts commit df1676e616.
Reason for revert: https://crbug.com/v8/7382#c26
Original change's description:
> [array] Implement Array.p.sort in Torque
>
> This CL implements a generic baseline version and 3 fastpaths, for
> various elements kinds, of Array.p.sort in Torque. Details can be found
> in the Design Doc: https://goo.gl/Ge321G.
>
> Performance impact on micro benchmarks depends on the element kind
> and whether the user provides a comparison function.
> For HoleySmi/HoleyElement we have a speedup between 1.5-1.8 across
> the board. For Dictionary we are slower in all micro benchmarks (0.7).
> For PackedSmi it depends on the call site and whether or not a
> comparison function is used.
>
> Detailed numbers: https://goo.gl/mTyPSb
>
> Bug: v8:7382
> Change-Id: I50acabd2032af0bc01d36b0de0f555d66be56a7e
> Reviewed-on: https://chromium-review.googlesource.com/1061523
> Commit-Queue: Simon Zünd <szuend@google.com>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53481}
TBR=cbruni@chromium.org,jgruber@chromium.org,szuend@google.com
Change-Id: I4c1b32a434d49caba67c80bccb068390607f90a2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7382
Reviewed-on: https://chromium-review.googlesource.com/1085407
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53494}
This makes stack checks in WasmCode independent of the underlying
Isolate by loading the limit address from the WasmInstanceObject instead
of embedding it into the instruction stream. It hence removes the last
use of the Isolate field from WasmGraphBuilder.
Additionally this introduces the notion of a "runtime stub" which
represents stub code global to the NativeModule that can be directly
called from each WasmCode in the same module. These stubs can act as
trampolines via which Isolate-independent WasmCode can enter other V8
builtins or runtime functions that remain Isolate-dependent. They will
eventually replace the current "trampoline" in a NativeModule.
R=titzer@chromium.org
BUG=v8:7424
Change-Id: Ie1f5582ee656b1ab7716ea06316d6e21a0268e74
Reviewed-on: https://chromium-review.googlesource.com/1078732
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53487}
This CL implements a generic baseline version and 3 fastpaths, for
various elements kinds, of Array.p.sort in Torque. Details can be found
in the Design Doc: https://goo.gl/Ge321G.
Performance impact on micro benchmarks depends on the element kind
and whether the user provides a comparison function.
For HoleySmi/HoleyElement we have a speedup between 1.5-1.8 across
the board. For Dictionary we are slower in all micro benchmarks (0.7).
For PackedSmi it depends on the call site and whether or not a
comparison function is used.
Detailed numbers: https://goo.gl/mTyPSb
Bug: v8:7382
Change-Id: I50acabd2032af0bc01d36b0de0f555d66be56a7e
Reviewed-on: https://chromium-review.googlesource.com/1061523
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53481}
This was renamed recently in the spec.
Change-Id: I825e47e8b4113ddb2c3356ee8e7663705ba65e1c
Reviewed-on: https://chromium-review.googlesource.com/1079851
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53448}
Compress the parameter count (and function length) stored in
SharedFunctionInfo to a uint16_t. This limits us to 2^16 - 1 parameters
per function, minus one for the "don't adapt arguments" sentinel value,
which is one fewer than Code::kMaxArguments was already. Anyway, 65534
arguments should be enough for anyone!
This drops SFI size by 4 bytes.
Bug: chromium:818642
Change-Id: I126bfb24453dcdc5087a104d3a12cf195a56fa9f
Reviewed-on: https://chromium-review.googlesource.com/1076627
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53447}
The regression test 2185-2 measured the Array.p.sort time for various
pre-sorted data configurations. This CL adds the various data
configurations to the ArraySortPreSorted benchmark and removes the
regression test altogether.
R=cbruni@chromium.org, jgruber@chromium.org
Change-Id: I6e2eb235e4a7578f4a107229bfc6a9e89a3aa5e3
Reviewed-on: https://chromium-review.googlesource.com/1076188
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53420}
This loads references to {null} values from the instance object instead
of embedding them into the generated code. It is one step towards making
the {WasmCode} objects independent of the Isolate.
Note that this also fixes an issue with the serializer/deserializer that
failed to properly serialize {null} values and accidentally collapsed
them to {undefined} values instead.
R=ahaas@chromium.org
TEST=mjsunit/regress/wasm/regress-7785
BUG=v8:7424,v8:7785
Change-Id: Ie436c2d96890e7c8c89ffe2bd4189a759254775b
Reviewed-on: https://chromium-review.googlesource.com/1070981
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53352}
At the moment, WebAssembly.instantiate(bytes) is implemented by
desugaring it to WebAssembly.compile(bytes).then(WebAssembly.instantiate).
The problem is that the {then} in this snippet is observable. With this
CL I introduce a CompilationResultResolver which allows to do the
desugaring internally and thereby make the {then} unobservable.
Unfortunately the result of WebAssembly.instantiate(bytes) is different
than the result of WebAssembly.instantiate(module). Therefore I also
introduced an InstantiationResultResolver for symmetry with
WebAssembly.compile.
R=mstarzinger@chromium.org
Bug: chromium:837417
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I2d98e03d65f2ada19041d5a9e2df5da91b24ccca
Reviewed-on: https://chromium-review.googlesource.com/1059783
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53347}
The slow test tests SmiLexicographicCompare on a large number of Smi comparisons;
we can disable this test for some debug/noopt builds without losing much coverage.
Bug: v8:7783
Change-Id: Iab40e596604bb957b4d3312073ad85dbac08c6a0
Reviewed-on: https://chromium-review.googlesource.com/1068190
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53333}
The timeout in the test is close to execution time in debug mode so it
fails occasionally. The test is measuring array slice algorithm
performance but changes unrelated to it affect the test result in debug
mode, therefore it should be skipped.
BUG=v8:7726
TEST=regress/regress-165637
Change-Id: Ib330d8e3c0d3f6a1150ccb59b60d17a41b87df87
Reviewed-on: https://chromium-review.googlesource.com/1071576
Commit-Queue: Miran Karić <miran.karic@mips.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53326}
This CL uses the new function pointers and generic features of Torque
to improve the performance of TypedArray.p.sort.
Instead of one Load/Store builtin that dispatches at runtime based on
the element kind, there are now many small builtins (one for each
element kind). The sorting algorithm then uses function pointers to
those small builtins, which get set once.
Changes in the relevant benchmarks:
Benchmark Original (JS) Current This CL
IntTypes 83.9 202.3 240.7
BigIntTypes 32.1 47.2 53.3
FloatTypes 99.3 109.3 129.3
Bug: v8:7382
Change-Id: I8684410524d546615b19f6edcbfdc615068196aa
Reviewed-on: https://chromium-review.googlesource.com/1070069
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53322}
Instead use the canonical empty fixed array. Some code assumes
that this is the only fixed array of length 0.
Bug: chromium:843062
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: If780acf50147c061a81f2ff2b31779fbd1c78559
Reviewed-on: https://chromium-review.googlesource.com/1064052
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53320}
Also mark another slow tests as SLOW.
TBR=jgruber@chromium.org
Bug: v8:7783
Change-Id: I69a8ac82e7898fa3b374c5b66a441f040d241413
Reviewed-on: https://chromium-review.googlesource.com/1069093
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53306}
The TC39 committee reached consensus to rename `flatten` to `flat`
during the May 22nd meeting. The corresponding patch to the proposal
is here:
093eacc7fe
Bug: v8:7220
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ie8049ae4d4589a4ae7fe3d203053cef798c135e4
Reviewed-on: https://chromium-review.googlesource.com/1069467
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53294}
The ECMAScript ⊃ JSON proposal doesn’t affect LineContinuation
grammar. These tests verify that the behavior remains the same when
the --harmony-subsume-json feature flag is enabled.
Bug: v8:7418
Change-Id: Iec5cb1bc112f278481ba1202f0c2b8693917843a
Reviewed-on: https://chromium-review.googlesource.com/1067463
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53270}
This is not web compatible, so let's delete the code.
Bug: v8:5536
Change-Id: I50506d37dcdff1f7f95577c47adcec653cc1f06e
Reviewed-on: https://chromium-review.googlesource.com/1064740
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53264}
Optimize String.p.split for the case when the separator is empty and
the subject is a direct one-byte string.
Bug: v8:7103
Change-Id: Ica277d2c426679a1f77a1ef8ecb523bd596f65fb
Reviewed-on: https://chromium-review.googlesource.com/1045950
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53260}
The js-to-wasm wrappers are shared across instances, so we cannot
directly call the instance-specific wasm-to-js wrappers. Instead, we
need to call via the import table.
R=titzer@chromium.org
Bug: chromium:843563
Change-Id: Ia882604f6769472fe2eb69176cbed728215ced29
Reviewed-on: https://chromium-review.googlesource.com/1064610
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53254}
ICU 61.1 was released in late March with CLDR 33.
Arabic number format change in CLDR 33 requires
a small adjustment in the test result.
See https://chromium-review.googlesource.com/c/chromium/deps/icu/+/1041578
for details on ICU 61.1.
NOTREECHECKS=true
Bug: chromium:838383, chromium:843073
Test: test262/intl402/*, intl/*
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I3778423b7dc67891767c95ea503e003013ae5b69
Reviewed-on: https://chromium-review.googlesource.com/1038230
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53251}
It is possible for user code to modify fast regexp result objects
before they are used e.g. by RegExp.p.match, so we may not make any
assumptions about their contents. The only exception is when the
RegExp itself is fast.
Bug: chromium:843022
Change-Id: I14eafbdfb2b2ced609da1391b57c73cbe167f7fb
Reviewed-on: https://chromium-review.googlesource.com/1061455
Reviewed-by: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53210}
Array.indexOf accepts an optional fromIndex argument. When non-negative,
this argument restricts the searched indices to those starting at
fromIndex:
[1, 2, 1].indexOf(1,1) == 2
When negative, it is meant to be added to the array length to provide
such initial index for the search:
[1, 2, 1].indexOf(1, -2) == 2
This transformation has been done by the non-optimised builtin but not
by the reducer. The CL adds this construction to the reducer.
Bug: chromium:842612
Change-Id: I0ff089997f4ebb4dc3c2923e52c382a8a96cd711
Reviewed-on: https://chromium-review.googlesource.com/1059628
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Vaclav Brozek <vabr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53197}
We were always using the instance we were currently building. If the
start function is an exported wasm function of another instance, use the
exporting instance instead.
R=titzer@chromium.org
Bug: chromium:843120
Change-Id: I141d272b947bef8e903be7208ddf6ce344e754c4
Reviewed-on: https://chromium-review.googlesource.com/1059620
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53190}
Since the code around that is quite fragile, and I plan to refactor it,
just add some tests to ensure that everything is and keeps working as
intended.
R=mstarzinger@chromium.org
Bug: v8:7758
Change-Id: Ib3814b93b465286d70b5669ed0161eecb9fc925a
Reviewed-on: https://chromium-review.googlesource.com/1059616
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53187}
The --trace-turbo flag would cause a crash when compiling a WASM_FUNCTION. It
was caused by assuming the OptimizedCompilationInfo had a SharedFunctionInfo
attached if the code isn't a stub and wasm functions are not considered as such.
In order to test this, we've added a new flag to specify were to dump JSON
files: --trace-turbo-path. This is used to make sure we do not leave lots of
files behind in the top-level directory. It should be useful as standalone
feature too.
Change-Id: Ia9442638d28100bea45a8683fb233803cc5393f2
Reviewed-on: https://chromium-review.googlesource.com/1030555
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53153}
The clusterfuzz issue crashes because VisitBinops expected only but 4
input operands but in the generated graph 5 input operands get created
The issue is fixed by increasing the size of the input operand buffer.
R=jarin@chromium.org
Bug: chromium:842501
Change-Id: I4bbb09a968e165e6f5a0a02d06eee97333f7aa38
Reviewed-on: https://chromium-review.googlesource.com/1056989
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53147}
We must not accept something of kBit representation as of
kWord32 representation (unless it's truncated accordingly).
Deopt instead.
Bug: v8:7740
Change-Id: Ib4f73600d66f8762a6e22f7ea1ce79e8ef451b34
Reviewed-on: https://chromium-review.googlesource.com/1054670
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53144}
This was already the case for 1-byte strings. This prevents crashes when
attempting to externalize such strings.
Bug: chromium:842078, v8:7464
Change-Id: I3092a6748edaf77b2689f7b6f6b949929998e508
Reviewed-on: https://chromium-review.googlesource.com/1054290
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53124}
Avoid writing NumberOfElements to HashTable when it hasn't changed as
the HashTable could be in RO_SPACE and this operation will crash.
Bug: v8:841592
Change-Id: Iffadd567fc10aa9cd13d953da81275464b16c6c0
Reviewed-on: https://chromium-review.googlesource.com/1052693
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53116}
This is a reland of e084eea628.
Undefined behavious was fixed in https://crrev.com/c/1051235.
Original change's description:
> Fix SourcePositionInfo for wasm
>
> In wasm we often don't have a SharedFunctionInfo associated with a
> compilation job, so we can't get a Script. Just print "unknown" in
> these cases (instead of crashing).
>
> R=titzer@chromium.org
> CC=herhut@chromium.org
>
> Bug: chromium:840757, v8:7738
> Change-Id: I850c6adfd9e07c9a0f6dd018f1a9314feb89d887
> Reviewed-on: https://chromium-review.googlesource.com/1049632
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53080}
TBR=titzer@chromium.org
Bug: chromium:840757, v8:7738
Change-Id: If04040a33766955cfed78e7c27226dd04c3f9b9f
Reviewed-on: https://chromium-review.googlesource.com/1051266
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53111}
Code comments are heap-allocated and never freed. We don't want to
attach them to the code object via a finalizer, since that could change
gc timing and heap layout when you enable code comments. They are used
to testing only anyway, so leaking is acceptable here.
R=bmeurer@chromium.org, jarin@chromium.org
Bug: v8:7738
Change-Id: I27b0f95db1d66b57f4f113c154f23edb84e6700d
Reviewed-on: https://chromium-review.googlesource.com/1051241
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53107}
Plus a bit of CSA typification.
Bug: v8:7725
Change-Id: I43fea4a4c0739f9c24d84035816b046e742372ee
Reviewed-on: https://chromium-review.googlesource.com/1051653
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53102}
The {CommentOperator}, used for implementing the --code-comments flag,
is not UBSan-safe. This CL fixes this and adds a test which uses code
comments.
R=bmeurer@chromium.org
Bug: v8:7744
Change-Id: Ia6ec509e77d998df085ac7377cb24854354e3aa2
Reviewed-on: https://chromium-review.googlesource.com/1051235
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53100}
... in order to be able to use it in other constants definitions in the header.
Bug: v8:7570
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Id5d6ae34ab401ecf063bf5897b87b6bb87c24960
Reviewed-on: https://chromium-review.googlesource.com/1032782
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53097}
This makes sure that the {WasmModuleObject} has been allocated before
any debug events are fired. Since {WasmScript} objects reference the
module object, it needs to be allocated earlier by now.
R=ahaas@chromium.org
TEST=debugger/regress/regress-crbug-840288
BUG=chromium:840288
Change-Id: I02783ce126c463ac953eb2192acb65f3a5d420a1
Reviewed-on: https://chromium-review.googlesource.com/1050246
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53084}
This reverts commit e084eea628.
Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20UBSanVptr/builds/3163
Original change's description:
> Fix SourcePositionInfo for wasm
>
> In wasm we often don't have a SharedFunctionInfo associated with a
> compilation job, so we can't get a Script. Just print "unknown" in
> these cases (instead of crashing).
>
> R=titzer@chromium.org
> CC=herhut@chromium.org
>
> Bug: chromium:840757, v8:7738
> Change-Id: I850c6adfd9e07c9a0f6dd018f1a9314feb89d887
> Reviewed-on: https://chromium-review.googlesource.com/1049632
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53080}
TBR=titzer@chromium.org,clemensh@chromium.org
Change-Id: Ib2020ea3f2b778df9fe50ccbe803938f2f4fd709
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:840757, v8:7738
Reviewed-on: https://chromium-review.googlesource.com/1051265
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53082}
In wasm we often don't have a SharedFunctionInfo associated with a
compilation job, so we can't get a Script. Just print "unknown" in
these cases (instead of crashing).
R=titzer@chromium.org
CC=herhut@chromium.org
Bug: chromium:840757, v8:7738
Change-Id: I850c6adfd9e07c9a0f6dd018f1a9314feb89d887
Reviewed-on: https://chromium-review.googlesource.com/1049632
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53080}
D8 enables the Wasm trap handler by default now, but we need to make sure the
older bounds check case still gets test coverage too, as bounds checks will
continue to be a supported configuration.
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I5b0bdded6929a9b3a8480e87d038398b8d2a0fd8
Reviewed-on: https://chromium-review.googlesource.com/1048835
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53078}
To stay compatible with JSC, Array.p.sort did a post-processing step
that shadowed elements from the prototype chain.
Some time ago, JSC changed and no longer exhibits this behavior. To
preserve comptibility and stay consistent with RemoveArrayHoles,
this CL removes this post-processing step altogether and adjusts
tests to expect the new behavior.
R=cbruni@chromium.org, jgruber@chromium.org
Bug: v8:7382
Change-Id: Iecedc37cea25001d3768b99a3a9de3a2db90ba82
Reviewed-on: https://chromium-review.googlesource.com/1047286
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53066}
This CL implements the functionality of SafeRemoveArrayHoles (JS),
which is used as a pre-processing step for sorting, in a runtime
function.
SafeRemoveArrayHoles is a generic fallback, when an existing runtime
function fails to remove holes/move undefineds to the end of an array.
This CL extends the existing runtime function to also support JSProxy
objects, and objects where indices have accessors.
R=cbruni@chromium.org, jgruber@chromium.org
Bug: v8:7382
Change-Id: I4881539cf2171caba08ff6e3e50320291f49839c
Reviewed-on: https://chromium-review.googlesource.com/1041950
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53060}
The hard-coded timeout in the test is so near, that e.g., adding DCHECKs pushes
the test over the limit. The test is ran with dcheck_always_on=true.
We shouldn't do any performance testing with dcheck_always_on=true; this creates
the wrong incentive to not add DCHECKs (or in this case, CLs which add more
DCHECKs or cause more DCHECKs to be hit cannot land at all).
Change-Id: Ia4d1b2b17ce5a5330b929f984253c89ba273f661
Reviewed-on: https://chromium-review.googlesource.com/1046548
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53032}
In order to get more test coverage (also on ClusterFuzz), stage Liftoff
and tier up behind --future.
R=hablich@chromium.org
CC=titzer@chromium.org
Bug: v8:6600
Change-Id: I718e17957b26f60aa4c002333035f693344806e0
Reviewed-on: https://chromium-review.googlesource.com/1042385
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Hablich <hablich@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52987}
This is a reland of a0c57368a9
Original change's description:
> [wasm] Maintain link from Instance to Module.
>
> This moves the link from a {WasmInstanceObject} to its corresponding
> {WasmModuleObject} into the right place and also makes it strong. This
> ensures that an instance always keeps the underlying module alive and
> hence removes the situation of an "orphaned instance".
>
> R=clemensh@chromium.org
>
> Change-Id: Id59f6a49740af8ef0248679c3d2c696bb9776944
> Reviewed-on: https://chromium-review.googlesource.com/1041691
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52942}
Change-Id: I9854400bfc1d22bd258f17118fcb7460cdc3acd5
Reviewed-on: https://chromium-review.googlesource.com/1043786
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52985}
Since 94ce16b704, when loading an iterator from null or undefined, we
generate the error message "x is not iterable" instead of the unwieldy
"Cannot read property 'Symbol(Symbol.iterator)' of undefined". However
Runtime::GetObjectProperty, which is used as slow path by LoadICs, did
not check for this case, leading to different messages being generated
depending on IC state.
Bug: chromium:823130
Change-Id: Ie98500b97efef401aac9880b9af47d58c3c2825d
Reviewed-on: https://chromium-review.googlesource.com/1042951
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52974}
This reverts commit a0c57368a9.
Reason for revert: Speculative revert due to failures with custom
snapshot:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/19061
Local bisect also points to this change:
http://shortn/_IhVxU2FKLu
Original change's description:
> [wasm] Maintain link from Instance to Module.
>
> This moves the link from a {WasmInstanceObject} to its corresponding
> {WasmModuleObject} into the right place and also makes it strong. This
> ensures that an instance always keeps the underlying module alive and
> hence removes the situation of an "orphaned instance".
>
> R=clemensh@chromium.org
>
> Change-Id: Id59f6a49740af8ef0248679c3d2c696bb9776944
> Reviewed-on: https://chromium-review.googlesource.com/1041691
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52942}
TBR=mstarzinger@chromium.org,clemensh@chromium.org
Change-Id: I1830e6ce14314f06f918a0c428182bfd68354ad9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/1041968
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52949}
This moves the link from a {WasmInstanceObject} to its corresponding
{WasmModuleObject} into the right place and also makes it strong. This
ensures that an instance always keeps the underlying module alive and
hence removes the situation of an "orphaned instance".
R=clemensh@chromium.org
Change-Id: Id59f6a49740af8ef0248679c3d2c696bb9776944
Reviewed-on: https://chromium-review.googlesource.com/1041691
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52942}
The first element of a given iterable argument can be a hole. Thus,
normalize the first element so that we can correctly format the
exception message with "undefined" for a hole element, instead of "NaN".
Bug: v8:7715
Change-Id: I62edd09e361ebeebab642bb82db29b73a2c7b193
Reviewed-on: https://chromium-review.googlesource.com/1038951
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52917}
We incorrectly used a TurboFan typer check for {0,10,undefined} on the
radix argument on Number.parseInt, which was internally widened to the
checking whether radix is in range 0-10 or undefined. This CL introduces
two separate checks.
Bug: chromium:838766
Change-Id: I5ebfc1c82bad5b9794b4f844e79e4df01f541a83
Reviewed-on: https://chromium-review.googlesource.com/1039197
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52914}
A stack overflow can be thrown by JSEntryStub, which means the
thread-in-wasm flag will not have the expected value. To accommodate
this, we now clear the flag during exceptional returns if it is set.
Bug: chromium:834624
Change-Id: I8359af79886ab98dfecc2fb39ca19118b7fa38eb
Reviewed-on: https://chromium-review.googlesource.com/1019570
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52891}
assertPromiseResult caused tests to timeout when the result of the
promise was unexpected, e.g. rejected instead of the expected
fulfillment. This CL cleans up the implementation of
assertPromiseResult, adds better stack traces, and adds tests for all
the important cases I can think of.
R=mathias@chromium.orgCC=clemensh@chromium.org
Bug: v8:7570
Change-Id: I6ecb94fd3e5151502edf73c3bcdeb518b80fc81c
Reviewed-on: https://chromium-review.googlesource.com/1032786
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52882}
Without this change, we could disable slow paths required when symbols
such as toStringTag are present on a receiver, but accessors or
interceptors are not (added in 31800120cc)
This change modifies this behaviour to not unset the previously set bit
if these forced slow path conditions are not met.
BUG=v8:7706
R=bmeurer@chromium.org
Change-Id: Id7bceb0e749da52e2dbcde0a310a865a89f24066
Reviewed-on: https://chromium-review.googlesource.com/1034210
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#52874}
* If the mutability of the global object doesn't match the module, then
it should throw a LinkError.
* There was a missing `return` when importing a Number as a mutable
global.
* All globals were being exported as immutable.
* Attempting to set the value of an immutable global should throw a
TypeError.
* The length of the setter function should be 1.
Bug: v8:7625
Change-Id: I08d6a428506a18db15eecadf4cbcee89e0658924
Reviewed-on: https://chromium-review.googlesource.com/1031626
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52865}
When WebAssembly.instantiate or WebAssembly.instantiateStreaming is
called in JavaScript, internally we transfrom it into
WebAssembly.compile(buffer).then(WebAssembly.instantiate). However,
modifying the prototype of WebAssembly.Module can change the result of
WebAssembly.compile(buffer). With this CL we make sure that even if the
result of WebAssembly.compile is modified, there is still no type
confusion. In the long term we have to do a refactoring and remove
this internal transformation.
R=mstarzinger@chromium.org
Bug: chromium:837417
Change-Id: I376068b8b8b01b991ec450162da6a62ae7030c62
Reviewed-on: https://chromium-review.googlesource.com/1032392
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52859}
In the case of an indirect call to an imported function, the target
instance stored in the IFT was actually wrong.
Bug: chromium:834619
Change-Id: Id2ac4158335ecf2b58e1983ce37df852a9ebd1b2
Reviewed-on: https://chromium-review.googlesource.com/1030174
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52831}
The new spec has two arguments, the first is the global descriptor, and
the second is the initial value:
new WebAssembly.Global({type: i32}, 42);
If the initial value argument is omitted, the value is set to 0.
Bug: v8:7625
Change-Id: I679d4b7c49c69ec7ffcdfeb8ae506fa7ab9bba95
Reviewed-on: https://chromium-review.googlesource.com/1028847
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52822}
This is a reland of f5d308510a
Original change's description:
> [builtins] Introduce further constant & external reference indirections
>
> This introduces further indirections for embedded constants and
> external references for builtins generated by the macro-assembler.
> The used mechanisms (LookupConstant and LookupExternalReference) are
> identical to what we already use in CSA.
>
> Almost all builtins are now isolate-independent in both release and
> debug modes. snapshot_blob.bin is roughly 670K smaller in embedded
> builds vs. non-embedded builds, while libv8.so is roughly 280K larger.
>
> Bug: v8:6666
> Change-Id: I7a6c2193ef5a763e6cf7543dd51597d6fff6c110
> Reviewed-on: https://chromium-review.googlesource.com/1006581
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52810}
TBR=mstarzinger@chromium.org
Bug: v8:6666
Change-Id: I73dfe207f2c5f79a9a06c165c75f5619e88a5a17
Reviewed-on: https://chromium-review.googlesource.com/1030550
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52819}
The WasmInstanceObject stores two new arrays:
- imported_mutable_globals_buffers_: a FixedArray of all the imported
globals' array buffers.
- imported_mutable_globals: a calloc'd array of Addresses pointing to
the mutable global in its array buffer.
When accessing the global, the generated code looks up the address in
imported_mutable_globals to find where to load/store.
Bug: v8:7625
Change-Id: I60844c21a788fce28f346455f10f2283d1c152e9
Reviewed-on: https://chromium-review.googlesource.com/1020602
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52794}
The mutable-globals proposal spec allows importing as Numbers or
WebAssembly.Global values, but always exports as WebAssembly.Global.
Since the value is always boxed, we can also import/export i64 values.
This CL also includes support for export of mutable globals. Since the
underlying ArrayBuffer that stores the global's value is shared between
the module and the WebAssembly.Global object, all that needs to be done
is remove the validation check.
Bug: v8:7625
Change-Id: I24d763e3bc193d229a7cc33b2f2690a473c6f2bc
Reviewed-on: https://chromium-review.googlesource.com/1018406
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52789}
Iterate over all descriptors instead of bailing out early and missing
enumerable properties later.
Bug: chromium:836145
Change-Id: I104f7ea89480383b6b4b9204942a166bdf8e0597
Reviewed-on: https://chromium-review.googlesource.com/1027832
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52786}
WebAssembly.instantiate is polymorphic, it can either take a module
object as parameter, or a buffer source which should be compiled first.
To share code between the two implementations, the module object was
first passed to a promise (i.e. which is the result of compilation).
However, passing the module object to a promise has a side effect if
the module object has a then function. To avoid this side effect I
remove this code sharing and call AsyncInstantiate directly in case
the parameter is a module object.
R=mstarzinger@chromium.org
Bug: chromium:836141
Change-Id: I67b76d0d7761c5aeb2cf1deda45b6842e494eed4
Reviewed-on: https://chromium-review.googlesource.com/1025774
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52755}
This is a reland of 5728b3fbc5
Original change's description:
> [builtins] Separate species protectors for Array, TypedArray, Promise
>
> Previously, there was one species protector for Array, TypedArray and
> Promise. This CL splits the protector in three separate ones. This means
> that invalidating one of them does not have negative performance
> implications for the other ones.
>
> Bug: chromium:835347, v8:7340
> Change-Id: Id84aa0071f17096192965264eb60ddadd1e8e73f
> Reviewed-on: https://chromium-review.googlesource.com/1023408
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52733}
Bug: chromium:835347, v8:7340
Change-Id: I0c0188a0723e206ddb362834bcf872b23cd7666d
Reviewed-on: https://chromium-review.googlesource.com/1023811
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52742}
This reverts commit 5728b3fbc5.
Reason for revert: Breaks noi18n build
Original change's description:
> [builtins] Separate species protectors for Array, TypedArray, Promise
>
> Previously, there was one species protector for Array, TypedArray and
> Promise. This CL splits the protector in three separate ones. This means
> that invalidating one of them does not have negative performance
> implications for the other ones.
>
> Bug: chromium:835347, v8:7340
> Change-Id: Id84aa0071f17096192965264eb60ddadd1e8e73f
> Reviewed-on: https://chromium-review.googlesource.com/1023408
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52733}
TBR=sigurds@chromium.org,bmeurer@chromium.org
Change-Id: Ied8b436e7991c759eb3b98702c142aa127a7e63c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:835347, v8:7340
Reviewed-on: https://chromium-review.googlesource.com/1024151
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52736}
Previously, there was one species protector for Array, TypedArray and
Promise. This CL splits the protector in three separate ones. This means
that invalidating one of them does not have negative performance
implications for the other ones.
Bug: chromium:835347, v8:7340
Change-Id: Id84aa0071f17096192965264eb60ddadd1e8e73f
Reviewed-on: https://chromium-review.googlesource.com/1023408
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52733}
Several functions on Array.prototype incorrectly threw a TypeError just
because their receiver was sealed or frozen.
Bug: v8:7677
Change-Id: I4ec38bfbf468f9bd676f1c0b341c8a50cf814f15
Reviewed-on: https://chromium-review.googlesource.com/1021870
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52718}
With certain ICU data bundles (such as the Node.js "small-icu"),
%GetDefaultICULocale() may return a more specific language tag (e.g.
"en-US") than what's available (e.g. "en"). In those cases, consider the
more specific language tag supported.
This CL also resolves the following Node.js issue:
https://github.com/nodejs/node/issues/15223
Bug: v8:7024
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ifda0776b3418734d5caa8af4e50c17cda95add73
Reviewed-on: https://chromium-review.googlesource.com/668350
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52716}
This CL adds a test for each typed element kind where the array to sort
consists of some max/min/zero elements.
When providing a custom compare function, the upcoming torque version
of TypedArray.p.sort needs to convert array elements to Number/BigInt
and back. The tests check the edge cases for that conversion.
R=jgruber@chromium.org
Bug: v8:7382
Change-Id: Ia85ca343f62ece208acdeb1595e94f17ce12b713
Reviewed-on: https://chromium-review.googlesource.com/1021080
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52710}
This makes testing with random gc stress use the status file entrees
for gc fuzzing as well, since many test cases not suitable for one, are
not suitable for the other.
This also skips two more tests that rely on assert(Un)Optimized, which
is unreliable with gc fuzzing.
TBR=sigurds@chromium.org
Change-Id: I33a617b251d5cf65cf6e486d07ec55cde050b8ab
Reviewed-on: https://chromium-review.googlesource.com/1021082
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52701}
In ArrayBuiltinsAssembler::VisitAllFastElementsOneKind(), we enumerate
an arrays elements, carefully checking for the "hole" when required.
This code is only called for arrays whose prototype is the initial array
prototype. And the path is only available when the initial array
prototype is free of elements. Since that's the case, we only need to
verify that the initial array prototype remains free of elements during
an iteration with javascript callbacks. We don't need a body of code
that can walk the prototype chain looking for elements visible through
the "hole" value. In practice, this code was never run.
Change-Id: Iba5e275c559d495aa1cf6a4f29d66e2ce475c981
Reviewed-on: https://chromium-review.googlesource.com/1015023
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52660}
Class fields needs to be initialized after `this` is bound, as per the
new spec change:
https://github.com/tc39/proposal-class-fields/pull/92
This CL moves the initialization of `this` from parser desugaring to
the bytecode generator.
Bug: v8:7647
Change-Id: I20f749403e5a4d2f06a39726cf39012ceb541987
Reviewed-on: https://chromium-review.googlesource.com/1014383
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52646}
Throw a TypeError if the length of a concat-spreadable object makes the
total length too large, as specified.
Bug: v8:7652
Change-Id: Ie3f694d64c949703edd733c0310cfb3f64b78a15
Reviewed-on: https://chromium-review.googlesource.com/1013714
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52644}
Now that tables and stack frames properly root instances, there is no
longer any need to disallow mutations that could unroot instances
while their code is on the stack.
Bug: v8:7232
Change-Id: I907b9522ac12ad7a67fb4124774713b6b3b40bb7
Reviewed-on: https://chromium-review.googlesource.com/1007004
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52629}
If the new length is too large, we must throw a TypeError.
Bug: v8:7652
Change-Id: I47268c04405f7a5f5bbc971cd434f2d786af9ca1
Reviewed-on: https://chromium-review.googlesource.com/1013563
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52624}
This adds tests for 'oddly' behaving comparison functions.
I.e. functions that cause an element kind change and/or
modify the array. The tests check that sort does not crash in these
instances.
R=jgruber@chromium.org
Bug: v8:7382
Change-Id: I4ac9aa081fda9088d1848a960dc66aba671872e5
Reviewed-on: https://chromium-review.googlesource.com/1010062
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52612}
Per the spec change at [1], Abstract Relational Comparison between a
BigInt and a String converts the String to BigInt via StringToBigInt
before performing the comparison. Before this change, the String was
converted to a Number, and a BigInt/Number comparison was performed.
[1] https://github.com/tc39/proposal-bigint/pull/139
Bug: v8:6791
Change-Id: I40b4f4ddc78977adb0d44180eb58e0f9a8a70cb6
Reviewed-on: https://chromium-review.googlesource.com/1004117
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52609}
This patch moves the desugaring from the parser to the bytecode
generator for super calls that have a spread at a non last position.
This allows us to have the post super() call behavior, such as
initializing instance fields in one place in VisitCallSuper.
Bug: v8:7642
Change-Id: I00a693beb7078a63282359c1121b66bb62c157c8
Reviewed-on: https://chromium-review.googlesource.com/1009907
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52596}
It is not safe to assume the first match is a string just
because the RegExp result is fast.
Bug: chromium:831943
Change-Id: Idd40f8b75312f0be54f45f626dc017339033abc6
Reviewed-on: https://chromium-review.googlesource.com/1009325
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#52578}
This test relies on allocation mementos remaining in place;
with the new forced GC in the deoptimizer, this test can't be
run with the deopt fuzzer on anymore.
Bug: v8:7644
Change-Id: I6271c00a7b6c4e90a5e190bac5debaafad03a0e3
Reviewed-on: https://chromium-review.googlesource.com/1004774
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52544}
On indirect function calls, if the corresponding table entry is empty,
we cannot call {GetCodeFromStartAddress}. In that case, the signature
check will fail anyway, so perform the signature check first, and only
get the code object if the check succeeds.
R=mstarzinger@chromium.org
Bug: chromium:831463
Change-Id: Iead949e4c12502b1a2a3949db2dabab4a184a1e7
Reviewed-on: https://chromium-review.googlesource.com/1005005
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52542}
This mjsunittest assumed specific internal types (i.e. Smi)
for certain fields; it generates some dozens of variants of
the test using new Function, but used the same property names
in all of them. This causes V8 to sometimes learn more general
types for fields (i.e. unboxed double), which the test did not
expect. This commit uses unique field names for each of the test
variants.
Change-Id: Ib1ecb3ae33a57c8a1293a29a2233dad4e16a39fb
Reviewed-on: https://chromium-review.googlesource.com/1004897
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52528}
The deadlock should be fixed with https://crrev.com/c/1002174.
This is a reland of 4d1c2907d3
Original change's description:
> Reland "[d8][wasm] Test wasm compilation completion"
>
> This is a reland of ed2605f040
>
> Original change's description:
> > [d8][wasm] Test wasm compilation completion
> >
> > d8 was recently changed to keep running until wasm compilation has
> > completed. This adds a message test to test that.
> >
> > R=ahaas@chromium.org
> >
> > Change-Id: I73af53b6df4ee5f9a6afd26cf2d71a269140465f
> > Reviewed-on: https://chromium-review.googlesource.com/966184
> > Reviewed-by: Andreas Haas <ahaas@chromium.org>
> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#52008}
>
> Change-Id: Iadbd5056dfa58da454956c4e89369af8b0455b35
> Reviewed-on: https://chromium-review.googlesource.com/975242
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52154}
Bug: chromium:824681
Change-Id: I4077645bcfcb2320f6573bb779027add36feee3f
Reviewed-on: https://chromium-review.googlesource.com/999632
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52505}
We hardcoded this accidentally in the original CL for the turbofan case,
instead we need to call JSConstructStubGeneric() which will return the
correct construct stub based on the harmony_restrict_constructor_return
flag.
Bug: chromium:829899
Change-Id: I6776a5daebd57d8881d926ad68595141312a877d
Reviewed-on: https://chromium-review.googlesource.com/1001893
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52470}
This change makes lifetime management of WasmCode much simpler.
By using the WasmInstanceObject as the context for WASM code execution,
including the pointer to the memory base and indirect function tables,
this keeps the instance alive when WASM code is on the stack, since
the instance object is passed as a parameter and spilled onto the stack.
This is in preparation of sharing the code between instances and
isolates.
Bug: v8:7424
R=mstarzinger@chromium.org
Change-Id: Ia35a3ce91a8f6135767fa764e185cde8bbc889f4
Reviewed-on: https://chromium-review.googlesource.com/997932
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52436}
The bug was fixed in https://crrev.com/c/995796, but this CL adds a
regression test to make sure it stays fixed.
Bug: chromium:827806
Change-Id: I9f4aed364bbd310af4253da457887a8b8015533a
Reviewed-on: https://chromium-review.googlesource.com/993237
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52409}
This is a reland of dbdede0101
after a webkit layout test (geolocation-api/timestamp.html) was
fixed by
https://chromium-review.googlesource.com/c/chromium/src/+/994343 .
Original change's description:
> Implement a new spec for timezone offset calculation
>
> https://github.com/tc39/ecma262/pull/778 was recently merged
> to Ecma 262.
>
> It changes the way to convert between "local time" and UTC in such
> a way that it'd work for all timezones whether or not there has
> been any change in the timezone offset of the standard time. For
> instance, Europe/Moscow and some parts of US state of Indiana have
> changed the standard (non-DST) timezone offset a few times. The
> previous spec assumes that the the standard timezone offset is
> constant, but the new spec take into account the offset change
> history.
>
> In addition, it specifies a new way to calculate the timezone
> offset during a timezone transition (either in and
> out of DST or timezone offset shift).
>
> During a negative transition (e.g. fall backward / getting
> out of DST), repeated times are to be interpreted as if the
> offset before the transition is in effect.
>
> During a positive transition (e.g. spring forward / getting
> into DST), skipped times are to be treated similarly. That
> is, they are to be interpreted as if the offset before the
> transition is in effect.
>
> With icu-timezone-data, v8 is compliant to the new spec for the
> past and the future as well as now whether or not the standard
> timezone offset of a given timezone has changed over time
> (e.g. Europe/Moscow, Pacific/Apia). With icu-timezone-data,
> Australia/Lord_Howe (30 minute DST change) also works per spec.
>
> Without icu-timezone-data, it works only for timezones of which
> the standard timezone offset is the same as the current offset
> (e.g. most North American timezones other than parts of Indiana)
> and of which the DST shift is an hour. For instance, it doesn't work
> for Europe/Moscow in 2010 when the standard timezone offset was
> +4h because the current (2018) standard timezone offset is +3h. Neither
> does it for Lord Howe in Australia with the DST shift of 0.5 hr.
>
> This CL used to require one of the two ICU CLs below, but not
> any more.
>
> https://chromium-review.googlesource.com/c/chromium/deps/icu/+/572652
> https://chromium-review.googlesource.com/851265 (a proposed CL to the
> upstream ICU).
>
> Bug: v8:3547,chromium:417640,v8:5714
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ib162295da5bee31b2390bd0918157014aebd3e33
> Reviewed-on: https://chromium-review.googlesource.com/572148
> Commit-Queue: Jungshik Shin <jshin@chromium.org>
> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52332}
Bug: v8:3547, chromium:417640, v8:5714
Change-Id: I47536c111143f75e3cfeecf5d9761c43a98a10f5
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/995971
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52372}
This reverts commit 57bf0bfefb.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> [wasm] Merge the WasmContext into WasmInstanceObject
>
> This change makes lifetime management of WasmCode much simpler.
> By using the WasmInstanceObject as the context for WASM code execution,
> including the pointer to the memory base and indirect function tables,
> this keeps the instance alive when WASM code is on the stack, since
> the instance object is passed as a parameter and spilled onto the stack.
> This is in preparation of sharing the code between instances and
> isolates.
>
> Bug: v8:7424
>
> Change-Id: Ic2e4b7bcc2feb20001d0553a615a8a9dff36317e
> Reviewed-on: https://chromium-review.googlesource.com/958520
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52361}
TBR=mstarzinger@chromium.org,titzer@chromium.org,ahaas@chromium.org,clemensh@chromium.org
Change-Id: I653e27b46dbc43ad773eda4292d521a508f42d79
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7424
Reviewed-on: https://chromium-review.googlesource.com/995418
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52364}
This change makes lifetime management of WasmCode much simpler.
By using the WasmInstanceObject as the context for WASM code execution,
including the pointer to the memory base and indirect function tables,
this keeps the instance alive when WASM code is on the stack, since
the instance object is passed as a parameter and spilled onto the stack.
This is in preparation of sharing the code between instances and
isolates.
Bug: v8:7424
Change-Id: Ic2e4b7bcc2feb20001d0553a615a8a9dff36317e
Reviewed-on: https://chromium-review.googlesource.com/958520
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52361}
Before reporting coverage data, we attempt to reduce clutter by
merging nested and consecutive ranges. Nested ranges are merged, if
the child range has the same execution count as the parent range.
Sibling ranges are merged, if one sibling begins where the other ends
and execution counts are identical.
This allowed an invalid transformation in which a range with an
execution count of 1 would be merged into the parent change, but the
sibling range with identical start and end points and a count of 0
would remain, effectively deleting the covered range.
For example:
{start: 0, end: 10, count: 1},
{start: 5, end: 8, count: 1}, // It's invalid to remove this.
{start: 5, end: 8, count: 0}
The fix is to separate the parent and sibling merge passes, and
removing duplicate ranges in-between.
Bug: chromium:827530
Change-Id: Ic35eae1d4a106746570ce9cb412ed6710ef6da53
Reviewed-on: https://chromium-review.googlesource.com/992114
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52352}
This CL allows builtin continuations to handle pending exceptions.
This implements exception handling for the promise constructor in
case of deoptimization.
Bug: v8:7584
Change-Id: Ib5df5eb6606abb3f9690f294397981858dbdbf25
Reviewed-on: https://chromium-review.googlesource.com/983912
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52340}
This reverts commit dbdede0101.
Reason for revert: Fails webkit_tests, blocks roll: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064
Original change's description:
> Implement a new spec for timezone offset calculation
>
> https://github.com/tc39/ecma262/pull/778 was recently merged
> to Ecma 262.
>
> It changes the way to convert between "local time" and UTC in such
> a way that it'd work for all timezones whether or not there has
> been any change in the timezone offset of the standard time. For
> instance, Europe/Moscow and some parts of US state of Indiana have
> changed the standard (non-DST) timezone offset a few times. The
> previous spec assumes that the the standard timezone offset is
> constant, but the new spec take into account the offset change
> history.
>
> In addition, it specifies a new way to calculate the timezone
> offset during a timezone transition (either in and
> out of DST or timezone offset shift).
>
> During a negative transition (e.g. fall backward / getting
> out of DST), repeated times are to be interpreted as if the
> offset before the transition is in effect.
>
> During a positive transition (e.g. spring forward / getting
> into DST), skipped times are to be treated similarly. That
> is, they are to be interpreted as if the offset before the
> transition is in effect.
>
> With icu-timezone-data, v8 is compliant to the new spec for the
> past and the future as well as now whether or not the standard
> timezone offset of a given timezone has changed over time
> (e.g. Europe/Moscow, Pacific/Apia). With icu-timezone-data,
> Australia/Lord_Howe (30 minute DST change) also works per spec.
>
> Without icu-timezone-data, it works only for timezones of which
> the standard timezone offset is the same as the current offset
> (e.g. most North American timezones other than parts of Indiana)
> and of which the DST shift is an hour. For instance, it doesn't work
> for Europe/Moscow in 2010 when the standard timezone offset was
> +4h because the current (2018) standard timezone offset is +3h. Neither
> does it for Lord Howe in Australia with the DST shift of 0.5 hr.
>
> This CL used to require one of the two ICU CLs below, but not
> any more.
>
> https://chromium-review.googlesource.com/c/chromium/deps/icu/+/572652
> https://chromium-review.googlesource.com/851265 (a proposed CL to the
> upstream ICU).
>
> Bug: v8:3547,chromium:417640,v8:5714
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ib162295da5bee31b2390bd0918157014aebd3e33
> Reviewed-on: https://chromium-review.googlesource.com/572148
> Commit-Queue: Jungshik Shin <jshin@chromium.org>
> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52332}
TBR=adamk@chromium.org,littledan@chromium.org,mlippautz@chromium.org,jshin@chromium.org
Change-Id: I6b3bf4427c761b106280d565a3912cd8e25cf87e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:3547, chromium:417640, v8:5714
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/994192
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52338}
This change implements the WebAssembly.Global object and constructor,
but none of the accessors or functions.
There is a new flag to enable this: --experimental-wasm-mut-global.
Change-Id: Ifeb270d57392d7ca0900c80c0038932c96ee8b61
Reviewed-on: https://chromium-review.googlesource.com/989296
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52335}
https://github.com/tc39/ecma262/pull/778 was recently merged
to Ecma 262.
It changes the way to convert between "local time" and UTC in such
a way that it'd work for all timezones whether or not there has
been any change in the timezone offset of the standard time. For
instance, Europe/Moscow and some parts of US state of Indiana have
changed the standard (non-DST) timezone offset a few times. The
previous spec assumes that the the standard timezone offset is
constant, but the new spec take into account the offset change
history.
In addition, it specifies a new way to calculate the timezone
offset during a timezone transition (either in and
out of DST or timezone offset shift).
During a negative transition (e.g. fall backward / getting
out of DST), repeated times are to be interpreted as if the
offset before the transition is in effect.
During a positive transition (e.g. spring forward / getting
into DST), skipped times are to be treated similarly. That
is, they are to be interpreted as if the offset before the
transition is in effect.
With icu-timezone-data, v8 is compliant to the new spec for the
past and the future as well as now whether or not the standard
timezone offset of a given timezone has changed over time
(e.g. Europe/Moscow, Pacific/Apia). With icu-timezone-data,
Australia/Lord_Howe (30 minute DST change) also works per spec.
Without icu-timezone-data, it works only for timezones of which
the standard timezone offset is the same as the current offset
(e.g. most North American timezones other than parts of Indiana)
and of which the DST shift is an hour. For instance, it doesn't work
for Europe/Moscow in 2010 when the standard timezone offset was
+4h because the current (2018) standard timezone offset is +3h. Neither
does it for Lord Howe in Australia with the DST shift of 0.5 hr.
This CL used to require one of the two ICU CLs below, but not
any more.
https://chromium-review.googlesource.com/c/chromium/deps/icu/+/572652https://chromium-review.googlesource.com/851265 (a proposed CL to the
upstream ICU).
Bug: v8:3547,chromium:417640,v8:5714
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ib162295da5bee31b2390bd0918157014aebd3e33
Reviewed-on: https://chromium-review.googlesource.com/572148
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52332}
This is a follow-up to https://chromium-review.googlesource.com/981687.
When a wasm function has a large stack frame, the x64 code generator
performs the stack overflow check before constructing the frame. This
requires the use of the `address_of_real_stack_limit` external
reference.
This reference is thread local, so if it is not relocated the stack
overflow check will always fail.
Bug: chromium:808848
Change-Id: I0edf3fe5a006242fc50d0bff44cd9dd0e7d85bd9
Reviewed-on: https://chromium-review.googlesource.com/982906
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52330}
When peeking into descriptor arrays (for Function.prototype.bind
inlining), we need to check the number of descriptors rather than
the length of the DescriptorArray.
Bug: chromium:825045
Change-Id: I55dbe1544e5e4cb8e23d873961c71ed12294d89c
Reviewed-on: https://chromium-review.googlesource.com/991812
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52315}
Because the GC is not aware of address space usage, this CL causes Wasm to
explicitly trigger a GC when its address space limit is reached in hopes of
being able to successfully allocate memory.
R=mlippautz@chromium.orgR=gdeepti@chromium.org
Change-Id: I2dcc560dd3d351dbfc4dda2f7c321c470a4d9fff
Reviewed-on: https://chromium-review.googlesource.com/985103
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52305}
For the wasm2js wrappers we have an optimization to call a JavaScript
function directly if the signature of the JavaScript function matches
the signature of the WebAssembly import. However, we are not supposed
to do this optimization if the imported function is a constructor,
because constructors can only be called with `new`. With this CL we
do not apply this optimization when the imported function is a
constructor.
R=titzer@chromium.org
Bug: chromium:824859
Change-Id: I1722367bd865d0b129eadf7d4849182410447179
Reviewed-on: https://chromium-review.googlesource.com/985974
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52296}
When a wasm function has a large stack frame, the x64 code generator
performs the stack overflow check before constructing the frame. This
requires using the `address_of_real_stack_limit` external reference, as
well as the `ThrowWasmStackOverflow` runtime function.
`ThrowWasmStackOverflow` is called via a generated trampoline, but it is
not a builtin, so the serializer adds it to the `stub_lookup_` map. This
map is encoded by using a monotonically increasing `stub_id` that starts
at 0.
When the function is serialized, a stub is differentiated from a builtin
by which half of the `i32` bits is used, upper or lower. A stub only
uses the lower 16 bits and a builtin only uses the upper 16 bits.
The deserializer checks whether the lower 16 bits are 0; if so, it is
determined to be a builtin. But if the `stub_id` is 0, then it will be
confused with builtin 0 (`RecordWrite`). Calling the builtin instead of
the stub causes a crash.
This CL starts all `stub_id`s at 1, which prevents the builtin/stub
confusion.
There is an additional bug that is not fixed by this CL:
`ThrowWasmStackOverflow` shouldn't be called at all. Currently it is
called because `address_of_real_stack_limit` is a thread-local value
that is not properly relocated.
Bug: chromium:808848
Change-Id: I06b3e650ea58ad717dcc47a3716443e16582e711
Reviewed-on: https://chromium-review.googlesource.com/981687
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52252}
--cleanup-code-caches-at-gc flag was removed in
b8b25e1c27,
rendering the test obsolete.
Change-Id: I34331d230102924899c89d3330379df51a489029
Reviewed-on: https://chromium-review.googlesource.com/980937
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52239}
The optimization was replacing
String.fromCharCode(x) == "y"
with x == y instead of (x & 0xFFFF) == y if x was outside
of uint16 range.
Bug: v8:7340, v8:7531
Change-Id: I967306cc2e05c28de82e16cf1b2312fe47396a7d
Reviewed-on: https://chromium-review.googlesource.com/979808
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52214}
This eases transition handlers caching and avoids memory overhead of
respective StoreHandler objects. In addition, it allows to use such
transition handlers on runtime side to make Object.assign implementation
a bit faster.
Bug: v8:5988
Change-Id: Iba660a11d4b300cd5f80615fb7e2608e53da8fee
Reviewed-on: https://chromium-review.googlesource.com/931701
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52187}
Also add a new fast-path for String.fromCodePoint.
R=neis@chromium.org
Bug: v8:7570, v8:7340
Change-Id: I6cd6e6fc98943588ecd646f24fcda043d4033ab0
Reviewed-on: https://chromium-review.googlesource.com/978244
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52183}
