Installation of the PrototypePropertyDependency, as well as GC, can
invalidate dependencies.
Bug: chromium:902552
Change-Id: Iabcce026c7475c722d19ac0b80758b22d9fbcfda
Reviewed-on: https://chromium-review.googlesource.com/c/1322450
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57343}
Previously, we finalize all compile jobs at once. This keeps the zone memory
in every compile job alive until the end. This contributes to a high peak
memory when many functions are compiled eagerly, for example when producing
cache data for the ServiceWorker cache.
Memory tracked by the AccountingAllocator in bytes, prior to this change in
the test case:
peak memory after init: 8192
peak memory after lazy compile: 41200
peak memory after lazy compile: 41200
peak memory after eager compile: 164256
With this change, if we are compiling on the main thread, we finalize every
compile job as soon as it is done and dispose the compile job and its zone
memory.
After this change:
peak memory after init: 8192
peak memory after lazy compile: 41200
peak memory after lazy compile: 41200
peak memory after eager compile: 41376
R=leszeks@chromium.org, rmcilroy@chromium.org
Bug: chromium:901329
Change-Id: Iae0c89396c89692c4ecdeec3970d3c62031d2bce
Reviewed-on: https://chromium-review.googlesource.com/c/1322949
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57340}
regress-336820 is testing that joining a very sparse
array to create a too-big string results in a RangeError,
rather than a crash. Reducing the largest index by
two orders of magnitude speeds this up (on x64 debug)
by 8x (from 8 seconds down to 1). Given that this test
takes nearly 9 minutes on arm64 sim debug, I hope to
see big ones there too.
Bug: v8:7783, chromium:336820
Change-Id: I74c22cf451a892eb039efc7f1259152921bf8530
Reviewed-on: https://chromium-review.googlesource.com/c/1323915
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57335}
The set of locales available there seems different from what
the tests expect.
Tbr: ftang@chromium.org
Bug: v8:8413
Change-Id: Icd4a072d1a7199772b7713485a558c5db54fc30d
Reviewed-on: https://chromium-review.googlesource.com/c/1323914
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57330}
This test takes nearly 10 minutes to run on arm64, and over 5 on arm.
Bug: v8:7783
Change-Id: I6798c001a76c59974729e4b2618167578eb50a1b
Reviewed-on: https://chromium-review.googlesource.com/c/1321034
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57327}
This is a reland of 007c003426
In the original commit below, the permutation of testing combinatino
test/intl/regress-8413.js take too long to complete in the TSAN
and fail by TIMEOUT. Therefore we fix it by splitting up the test to
smaller tests, one for each property type in Table 5 of ECMA402.
Original change's description:
> [Intl] Handle 'c' pattern for DateTimeFormat
>
> Handle the pattern 'c' return by ICU in Intl.DateTimeFormat
> for weekday standalone form.
> Add regression test to ensure all the standalone pattern return
> option are in the expected list.
>
> Bug: v8:8413
> Change-Id: I9ab42383e3882ef1720606830624775e2748fccb
> Reviewed-on: https://chromium-review.googlesource.com/c/1318092
> Reviewed-by: Jungshik Shin <jshin@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Commit-Queue: Frank Tang <ftang@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57299}
Bug: v8:8413
Change-Id: I7a4bfd0876e4afd3eddaf3cb3d9027db075a1e3c
Reviewed-on: https://chromium-review.googlesource.com/c/1321893
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57324}
This is a bit of a performance bottleneck currently and
we're planning on improving performance by adding caching.
These benchmarks will allow us to measure the improvements
Add benchmark tests for
String.prototype.localeCompare()
Date.prototype.toLocaleString()
Date.prototype.toLocaleDateString()
Date.prototype.toLocaleTimeString()
Number.prototype.toLocaleString()
Run with
python -u tools/run_perf.py --binary-override-path \
out/x64.release/d8 --filter "JSTests/Strings/StringLocaleCompare" \
test/js-perf-test/JSTests.json
python -u tools/run_perf.py --binary-override-path \
out/x64.release/d8 --filter "JSTests/Dates" \
test/js-perf-test/JSTests.json
python -u tools/run_perf.py --binary-override-path \
out/x64.release/d8 --filter "JSTests/Numbers" \
test/js-perf-test/JSTests.json
Before the landing of dffaff7769
git reset --hard 474a6d6364
got
StringLocaleCompare-Strings(Score): 13240000
toLocaleDateString-Dates(Score): 1877000
toLocaleString-Dates(Score): 1197000
toLocaleTimeString-Dates(Score): 2147000
toLocaleDateString-Dates(Score): 1908000
After the landing of dffaff7769
git reset --hard dffaff7769
got
StringLocaleCompare-Strings(Score): 97182
toLocaleDateString-Dates(Score): 10436
toLocaleString-Dates(Score): 10436
toLocaleTimeString-Dates(Score): 10669
toLocaleString-Numbers(Score): 2876
Bug: chromium:901748
Change-Id: Ibfea85fe668f1bfaacb2dfe08368cd920d2bbfc6
Reviewed-on: https://chromium-review.googlesource.com/c/1318099
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57323}
That allows us to keep on running further without explicit RETURN_IF
Bug: v8:8363, v8:7926
Change-Id: If1424a1dae656ac725a8443b09ea1b8cc25dfcb1
Reviewed-on: https://chromium-review.googlesource.com/c/1322953
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57319}
Compilation units currently contain pointers into allocated space that
contains the code of the respective function. This requires us to keep
the StreamingDecoder alive as long as compilation is still running
(including tiering).
This CL refactors this by having an additional redirection
(WireBytesStorage) which can point to either the StreamingDecoder or
the NativeModule. We only keep the code section buffer alive as long as
the StreamingWireBytesStorage is still in use.
I will further refactor memory ownership in a follow-up CL to not make
the AsyncCompileJob keep the StreamingDecoder alive.
R=ahaas@chromium.org
Bug: v8:8343,v8:7921,v8:8050
Change-Id: I780582c3217abf64000454f2c9c108b9ac9fbff1
Reviewed-on: https://chromium-review.googlesource.com/c/1319588
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57317}
Recursion is really only useful for sloppy eval and with scopes, which are
uncommon.
Change-Id: I2560b600cab9b00a82d5837a3daa28c8d38c2959
Reviewed-on: https://chromium-review.googlesource.com/c/1322451
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57316}
This is a reland of b8e8b0de4f
Original change's description:
> [ptr-compr] Fix incorrectly used machine types
>
> in TurboFan, CSA, Wasm and compiler tests. Tagged values decompression
> logic will depend on the machine type of the value being loaded so it must
> be correct.
>
> Bug: v8:7703
> Change-Id: Ia9e7cc1e273e5a458d9de8aaa4adb0c970413b8b
> Reviewed-on: https://chromium-review.googlesource.com/c/1319573
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57280}
Bug: v8:7703
Change-Id: I2c740bab9a800520ebfb83334345bd5641b7e408
Reviewed-on: https://chromium-review.googlesource.com/c/1320850
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57314}
in order to make the test compatible with the pointer compression friendly
heap layout.
Bug: v8:8182
Change-Id: I34a0c597b70687f7ae7dad19df60c94520fa349f
Reviewed-on: https://chromium-review.googlesource.com/c/1317818
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57310}
Adds a helper macro "CloneIfMutablePrimitive", which tests if the
operand is a MutableHeapNumber, and if so, clones it, otherwise
returning the original value.
Also modifies the signature of "CopyPropertyArrayValues" to take a
"DestroySource" enum, indicating whether or not the resulting object is
supplanting the source object or not, and removes all default
parameters from that macro (which were not used anyways).
This corrects the issue reported in chromium:901301, where
StaNamedOwnProperty was replacing the value of a MutableHeapNumber
referenced by both the cloned object and the source object.
BUG=chromium:901301, v8:7611
R=cbruni@chromium.org, jkummerow@chromium.org
Change-Id: I43df1ddc84dfa4840e680b6affeba452ce0b6629
Reviewed-on: https://chromium-review.googlesource.com/c/1318096
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57304}
This test takes over 8 minutes to run on arm64 debug.
Also removed redundant skips for another DFG test.
Change-Id: I9c66c90fb3dc5c42ca04010e2d0245626a867ebd
Reviewed-on: https://chromium-review.googlesource.com/c/1321037
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57303}
This CL only clears the wasm translations that correspond to the context
group being reset instead of clearing all.
R=clemensh@chromium.org,kozyatinskiy@chromium.org
BUG=chromium:892864
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ib5af0489cbdb7c9b1571cb9cf935fda3bee14015
Reviewed-on: https://chromium-review.googlesource.com/c/1292676
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57302}
'simulator_run' is now used exclusively in test/*/*.status.
Change-Id: I501b7ffd19e2476f4c803ed3d25cba69d67039fa
Reviewed-on: https://chromium-review.googlesource.com/c/1318610
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57300}
Handle the pattern 'c' return by ICU in Intl.DateTimeFormat
for weekday standalone form.
Add regression test to ensure all the standalone pattern return
option are in the expected list.
Bug: v8:8413
Change-Id: I9ab42383e3882ef1720606830624775e2748fccb
Reviewed-on: https://chromium-review.googlesource.com/c/1318092
Reviewed-by: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57299}
This test currently takes nearly 10 minutes on the arm64 debug builder.
Bug: v8:7783
Change-Id: I500fc026b01873e666f32062d790eca3f34455b9
Reviewed-on: https://chromium-review.googlesource.com/c/1318495
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57298}
simulator takes too long to run.
Change-Id: I77f6e932129bfed7d1cdb7e9ccf78a4608554ff5
Reviewed-on: https://chromium-review.googlesource.com/c/1320389
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#57296}
This reverts commit b8e8b0de4f.
Reason for revert:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Arm%20-%20debug/8276
Original change's description:
> [ptr-compr] Fix incorrectly used machine types
>
> in TurboFan, CSA, Wasm and compiler tests. Tagged values decompression
> logic will depend on the machine type of the value being loaded so it must
> be correct.
>
> Bug: v8:7703
> Change-Id: Ia9e7cc1e273e5a458d9de8aaa4adb0c970413b8b
> Reviewed-on: https://chromium-review.googlesource.com/c/1319573
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57280}
TBR=mstarzinger@chromium.org,ishell@chromium.org
Change-Id: Ia97d5bfebf8d8fe1b2b7607f63024b60cf2c584f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7703
Reviewed-on: https://chromium-review.googlesource.com/c/1320349
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57294}
Rename variables and flag names so that the classes can be reused
by private methods implementation.
In particular:
Rename "fields" to "members" in the initializer so that we can
initialize both fields and private methods/accessors there,
for example:
instance_fields_initializer -> instance_members_initializer
InitializeClassFieldsStatement -> InitializeClassMembersStatement
Rename "private field" to "private name" for the private symbols
used to implement private fields so that we can use them to
store private methods/accessors later as well, for example:
private_field_name_var -> private_name_var
NewPrivateFieldSymbol -> NewPrivateNameSymbol
The follow-on is in
https://chromium-review.googlesource.com/c/v8/v8/+/1301018
The design doc is in
https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit?usp=sharing
Bug: v8:8330
Change-Id: I1cdca8def711da879b6e4d67c5ff0a5a4a36abbe
Reviewed-on: https://chromium-review.googlesource.com/c/1312597
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#57289}
These tests are also used for streaming. This CL changes the test to
actually output the exception that unexpectedly happened.
R=ahaas@chromium.org
Bug: v8:7921
Change-Id: Ia9c91a7d3d9452f9c0180329a5434f049b56c3c8
Reviewed-on: https://chromium-review.googlesource.com/c/1319755
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57284}
Any sane platform would process foreground tasks in a FIFO order. Hence
our mock platform in the tests should do the same.
R=ahaas@chromium.org
Bug: v8:7921
Change-Id: Iafe1d9f2eb2a0c168f7e994f05b054756ef9e4af
Reviewed-on: https://chromium-review.googlesource.com/c/1319754
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57283}
in TurboFan, CSA, Wasm and compiler tests. Tagged values decompression
logic will depend on the machine type of the value being loaded so it must
be correct.
Bug: v8:7703
Change-Id: Ia9e7cc1e273e5a458d9de8aaa4adb0c970413b8b
Reviewed-on: https://chromium-review.googlesource.com/c/1319573
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57280}
The array length is modifiable by user code that is called as a
side-effect during the sorting algorithm. We thus cannot base any
guarantees on the current length, but must reference the initially-read
array length instead.
Note that even though the algorithm may read and write from beyond
the current array length value, this adheres to the spec, which only
requires accesses to be within the original array dimensions (i.e.: 0
<= i < original array length).
Bug: chromium:901633
Change-Id: Id765e80d4231ff6f2a73e040ec94c2b07f8c5b0f
Reviewed-on: https://chromium-review.googlesource.com/c/1317814
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57279}
- Fix ParseBCP47 to return just the extension. The second argument to
substr function is actually the length, not the end position of the
substring :')
- Remove extension keys that aren't part of the relevant extension keys
- Use 'ca' as an relevant extension key for DateTimeFormat
- Use the canonicalized locale tag after create the ICU locale is
created, rather than the input locale tag.
Bug: chromium:895942, v8:5751
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I189709714d847e684b04409b734a60ff04ed7dd2
Reviewed-on: https://chromium-review.googlesource.com/c/1291076
Reviewed-by: Frank Tang <ftang@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57274}
This is to ensure the snapshot is deterministic.
Internal fields can contain:
- reference to heap object
- embedder-defined aligned pointer
- a smi
The latter two are not distinguishable by V8, so if the serializer
callback returns non-zero value, we consider it to be an aligned pointer
and clear it to ensure that the snapshot does not contain memory
addresses that may not be deterministic. If the callback returns
{ nullptr, 0 } as result, we consider it to be a smi or some in-place
data that we then serialize verbatim.
R=jgruber@chromium.org
Bug: chromium:870584
Change-Id: I3cf9abf135ffd28d8138fa32636b12596b076e13
Reviewed-on: https://chromium-review.googlesource.com/c/1304441
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57272}
Currently to obtain a v8::Array out of a C array or a std::vector,
one needs to loop through the elements and call array->Set() multiple
times, and these calls go into v8::Object::Set() which can be slow.
This patch adds a new Array::New overload that converts a
Local<Value>* with known size into a Local<Array>.
Change-Id: I0a768f0e18eec51e78d58be455482ec6425ca188
Reviewed-on: https://chromium-review.googlesource.com/c/1317049
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#57261}
Unlike other v8::Context getter on v8::Isolate, the v8::Context returned
by GetEnteredOrMicrotaskContext may be non-NativeContext. However,
Blink implicitly assumes all v8::Context is backed by NativeContexts.
This CL updates GetEnteredOrMicrotaskContext() to check the resulting
Context is NativeContext, and updates callers of EnterMicrotaskContext
to use NativeContext.
Change-Id: Ifae528f4ce8feb067f4ad1a43330dc55f4a8ed79
Reviewed-on: https://chromium-review.googlesource.com/c/1301653
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Taiju Tsuiki <tzik@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57259}
This should allow for better parallelization when running these tests.
Change-Id: Ib3cae7d6e8f0d2608470ca616eeac7eecae3b7ab
Reviewed-on: https://chromium-review.googlesource.com/c/1318094
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57256}
In particular FunctionLiteral body. Now clients cannot use
function_literal->body() == nullptr anymore to figure out whether it was
preparsed; but have to check the eager compile hint.
Change-Id: Ia0d3a6b51c6fb7e803157e98a9d224224e03c8a7
Reviewed-on: https://chromium-review.googlesource.com/c/1317811
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57246}
A Property access is only a valid reference expression if the accessed object
is a valid expression.
Bug: v8:8409
Change-Id: I9bc9ac60ca3bf4e261d10af97aba18e9db2085ea
Reviewed-on: https://chromium-review.googlesource.com/c/1317816
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57244}
- Add the WeakRef class and its deref() function.
- Add WeakFactory.prototype.makeRef
- Implement the "keep during job" behavior for WeakRef constructor and deref().
- Here we keep the targets alive longer than until the end of the job
(microtask), contradicting the spec. However, this is probably the indended
behavior, see https://github.com/tc39/proposal-weakrefs/issues/39 .
BUG=v8:8179
Change-Id: I41990d41ac1799e34f675d8431b9a7aa7ed3d48d
Reviewed-on: https://chromium-review.googlesource.com/c/1306435
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57242}
This is resurrecting an optimization from the pre-torque version.
Avoid allocating another sequential string for the result when there's only one
element, just return the ToString-ed element. This not only saves time writing
to this destination string, but also reduce GC pressure.
The System Health Memory Benchmark (load:media:google_images) exposed this missing
optimization with a 15% regression in memory usage. Very large external strings
were being copied into V8's heap as sequential string.
Bug: chromium:896612
Change-Id: Ieb61906f64100cdc15bf96f3ebcccb1207f75356
Reviewed-on: https://chromium-review.googlesource.com/c/1316620
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#57241}
This is a reland of 7bd9eb7e1e. No changes
to that patch other than adding a test case. The bug that lead to the
revert has been fixed in 9bf8f72c5b.
Original change's description:
> Add fast paths to Array.from.
>
> This reuses the fast path from IterableToList for Array.from. The fast
> paths are taken when .from is called with the receiver Array and the only
> argument is the iterable (no mapping function or thisArg).
>
> Bug: v8:7980
> Change-Id: I975b0c5e3f838262d7b71ad4dec5111fb031d746
> Reviewed-on: https://chromium-review.googlesource.com/c/1297322
> Commit-Queue: Hai Dang <dhai@google.com>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56993}
Bug: v8:7980
Change-Id: Id081837946c0989ec2b31ce991f48d09e0219b09
Reviewed-on: https://chromium-review.googlesource.com/c/1317586
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57240}
The relocation mode in question was by now only used in tests to model a
wrapper call from wrapper code (on the GC'ed heap) to a non-movable wasm
code object. Instead of using a special relocation mode, we switch to
using the existing {EXTERNAL_REFERENCE} mode similar to other static C++
functions called from generated code.
R=sigurds@chromium.org
BUG=v8:8238
Change-Id: I30af98b92aed207c52ccccaf018a455ecac39c2b
Reviewed-on: https://chromium-review.googlesource.com/c/1309821
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57239}
This introduces a new syntax for identifiers and calls: modulename::foo.
Such a name is resolved by trying to find a module modulename in one of
the parent scopes and looking for foo there. So this roughly corresponds
to C++ qualified namespace lookup.
Bug: v8:7793
Change-Id: Iedc43e6ebe125cd74575cbbcbf990bbcc0155a1f
Reviewed-on: https://chromium-review.googlesource.com/c/1309818
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57238}
The fast paths for sets and maps did not support allocation in
large object space, yet they were taken in these cases. This CL
adds support, simply by passing the kAllowLargeObjectAllocation
argument to AllocateJSArray.
It also changes the fast path for strings to use this argument
rather than take the slow path.
Bug: v8:7980, v8:8410
Change-Id: I18e88cb4ceb7ebeca250edd8b8b0eb401fdbd6e4
Reviewed-on: https://chromium-review.googlesource.com/c/1317507
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57232}
- Name lookup in module scopes has namespace semantics now: All
overloads from all parent modules are combined before overload
resolution.
- Allow overloads of different callables: runtime-functions,
macros, builtins, and generics.
- The duplication between the DeclarationVisitor and the
ImplementationVisitor is removed: The DeclarationVisitor creates
declarables for everything except for implicit generic specializations.
The ImplementationVisitor iterates over declarables.
The DeclarationVisitor only looks at the header of declarations, not
at the body.
- Modules become Declarable's, which will enable them to be nested.
- Modules replace the existing Scope chain mechanism, which will make it
easier to inline macros.
- The DeclarationVisitor and Declarations become stateless. All state is
moved to contextual variables and the GlobalContext.
- Implicit specializations are created directly from the
ImplementationVisitor. This will enable template parameter inference.
- As a consequence, the list of all builtins is only available after the
ImplementationVisitor has run. Thus GenerateBuiltinDefinitions has to
move to the ImplementationVisitor. Also, this makes it necessary to
resolve the link from function pointer types to example builtins only
at this point.
Bug: v8:7793
Change-Id: I61cef2fd3e954ab148c252974344a6e38ee2d01d
Reviewed-on: https://chromium-review.googlesource.com/c/1304294
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57231}
This is a reland of 7350e7b220
Disabled LayoutTest that was causing issues and will rebaseline once this has rolled.
Original change's description:
> Get BytecodeArray via current frame where possible.
>
> With BytecodeArray flushing the SFI->BytecodeArray pointer will become pseudo weak.
> Instead of getting the bytecode array from the SFI, get it from the frame instead
> (which is a strong pointer). Note: This won't actually change behaviour since the
> fact that the bytecode array was on the frame will retain it strongly, however it
> makes the contract that the BytecodeArray must exist at these points more explicit.
>
> Updates code in runtime-profiler.cc, frames.cc and runtime-test.cc to do this.
>
> BUG=v8:8395
>
> Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
> Change-Id: Id7a3e6857abd0e89bf238e9b0b01de4461df54e1
> Reviewed-on: https://chromium-review.googlesource.com/c/1310193
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57198}
TBR=mythria@chromium.org
Bug: v8:8395
Change-Id: I63044138f876a1cdfb8bb71499732a257f30d29a
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/c/1314336
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57219}
- Avoid allocating AstRawString in the preparser
- Use fast LiteralEquals to compare the directive.
Bug: chromium:901250
Change-Id: I178aca812f6c0ffa28d7f48b707316a5a99a2ac0
Reviewed-on: https://chromium-review.googlesource.com/c/1314570
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57217}
This makes clear that some benchmarks where Array.from is used to
clone the array are very fast because the array is COW, and the
added benchmarks for non-COW arrays are not as fast. COW-ness does
not affect benchmarks where Array.from is called with a callback
function.
Change-Id: Ie9dd5507df5dd7501ac955dba4d3682c4a54548e
Reviewed-on: https://chromium-review.googlesource.com/c/1314333
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Hai Dang <dhai@google.com>
Cr-Commit-Position: refs/heads/master@{#57208}
We don't have any tests which run multiple isolates concurrently and
starts a profiler in each of them. This test is a basic starting point
so that we can check for flakiness caused by races or interrupts.
The profiling mechanisms should be totally separate for two isolates,
so this should (theoretically) not cause any problems.
A use case for multiple isolates is for workers or in Node via cloud
functions, so we should get some more coverage here.
Change-Id: I0ca6d1296bc7bae7238c51b4487259d09e38d690
Reviewed-on: https://chromium-review.googlesource.com/c/1309823
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57207}
Restructure the code a little, and change how we detect sloppy block function
redeclaration so we don't dereference a possibly nullptr function.
Bug: chromium:900786
Change-Id: Ief124fe767603ca36f4dc8865c4aeb3e0635b4cf
Reviewed-on: https://chromium-review.googlesource.com/c/1314331
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57206}
This reverts commit 7350e7b220.
Reason for revert: Braking layout test, blocking the roll, see
https://bugs.chromium.org/p/v8/issues/detail?id=8405
Original change's description:
> Get BytecodeArray via current frame where possible.
>
> With BytecodeArray flushing the SFI->BytecodeArray pointer will become pseudo weak.
> Instead of getting the bytecode array from the SFI, get it from the frame instead
> (which is a strong pointer). Note: This won't actually change behaviour since the
> fact that the bytecode array was on the frame will retain it strongly, however it
> makes the contract that the BytecodeArray must exist at these points more explicit.
>
> Updates code in runtime-profiler.cc, frames.cc and runtime-test.cc to do this.
>
> BUG=v8:8395
>
> Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
> Change-Id: Id7a3e6857abd0e89bf238e9b0b01de4461df54e1
> Reviewed-on: https://chromium-review.googlesource.com/c/1310193
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57198}
TBR=rmcilroy@chromium.org,mythria@chromium.org
Change-Id: Ie5db0ec1d68ca01d62e9880a4476704ad4d013b5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8395
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/c/1314330
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57205}
The fast-path in the `ArrayPrototypeLastIndexOf` torque implementation
didn't check that the `fromIndex` is within the bounds of the JSArray
_AFTER_ the call to ToInteger, which can have arbitrary side-effects,
i.e. it can change the length of the array.
R=yangguo@chromium.org
Bug: chromium:898785
Change-Id: I7ef84143ec8c33148f6e9d451bd52769d5074fb4
Reviewed-on: https://chromium-review.googlesource.com/c/1314329
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57204}
To fix the to-be-landed-soon test262 test failure in
test262/intl402/DateTimeFormat/prototype/resolvedOptions/order
The spec change from "any order" to "table " order
in https://github.com/tc39/ecma402/pull/279
Change the order of creating each property
Move the code inside SetPropertyFromPattern into ResolvedOptions
so we can easily follow the spec.
Bug: v8:8379
Change-Id: Ibe9ea72a2557474fd81a9f350fffa298f4b7738f
Reviewed-on: https://chromium-review.googlesource.com/c/1302803
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57200}
With BytecodeArray flushing the SFI->BytecodeArray pointer will become pseudo weak.
Instead of getting the bytecode array from the SFI, get it from the frame instead
(which is a strong pointer). Note: This won't actually change behaviour since the
fact that the bytecode array was on the frame will retain it strongly, however it
makes the contract that the BytecodeArray must exist at these points more explicit.
Updates code in runtime-profiler.cc, frames.cc and runtime-test.cc to do this.
BUG=v8:8395
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Id7a3e6857abd0e89bf238e9b0b01de4461df54e1
Reviewed-on: https://chromium-review.googlesource.com/c/1310193
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57198}
Change the order of creating property for the return object
of Intl.NumberFormat.property.resolvedOptions()
according to the table in the spec.
This is due to spec change in from "any order" to "table "
in https://github.com/tc39/ecma402/pull/279
Failure w/o fixing it will happen once we land
test262/intl402/NumberFormat/prototype/resolvedOptions/order
Bug: v8:8378
Change-Id: Ic68fcfeba78af87d9bbd13c935ad9a91e76f4965
Reviewed-on: https://chromium-review.googlesource.com/c/1303195
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57195}
This was removed from gtest and is necessary to roll gtest in
Chromium.
TBR=adamk@chromium.org
Bug: chromium:893369
Change-Id: I21762aa65ab2fc3f52731e7e812f0bf155f285e6
Reviewed-on: https://chromium-review.googlesource.com/c/1310598
Commit-Queue: Fabrice de Gans-Riberi <fdegans@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57193}
This is preparation to support the Torque port of Object.fromEntries,
including tests to make sure that the interface of the iterator functions
is correct and compiles when used.
Change-Id: I2a30ef80a80f42d4744a92746c8cd383abc10c19
Reviewed-on: https://chromium-review.googlesource.com/c/1303726
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57192}
Fix the broken test of the to-be-landed
test262/intl402/ListFormat/prototype/resolvedOptions/order
The ecma402 spec change from "any order" to "table " order
in https://github.com/tc39/ecma402/pull/279 the intl* proposals
will follow.
Bug: v8:7871
Change-Id: If47ab44791920c23fe2e1101e60205589d0ac093
Reviewed-on: https://chromium-review.googlesource.com/c/1302058
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57191}
The Intl.RelativeTimeFormat.prototype.formatToParts does not
correctly implement the spec. Change the implementation by refactoring
the JSNumber::FormatToParts and delegate part of the
JSRelativeTimeFormat::FormatToParts to call the new refactored function.
Bug: v8:8382
Change-Id: Ie153aa256ca78ce71c92efcdad55262564349ca9
Reviewed-on: https://chromium-review.googlesource.com/c/1305936
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57188}
This is a reland of 0f15ed05b9
Original change's description:
> [torque]: Implement catch handlers for try blocks
>
> In addition (and in combination), try statements now support "catch"
> clauses at the end that catch JavaScript exceptions throw by any builtin
> or runtime function contained in the try block:
>
> try {
> ThrowTypeError(context, ...);
> }
> catch (e) {
> // e has type Object
> }
>
> Bug: v8:7793
> Change-Id: Ie285ff888c49c112276240f7360f70c8b540ed19
> Reviewed-on: https://chromium-review.googlesource.com/c/1302055
> Commit-Queue: Daniel Clifford <danno@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57169}
Bug: v8:7793
Change-Id: I3c4182303acfdfa625654976bec372cf531d954f
Reviewed-on: https://chromium-review.googlesource.com/c/1310295
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57184}
- introduced ValueMirror interface, this interface contains methods to generate
different protocol entities,
- introduced DebugPropertyIterator, this iterator iterates through object properties
in the following order: exotic indices, enumerable strings, all other properties,
- removed all injected script infra, e.g. closure compiler,
R=dgozman@chromium.orgTBR=yangguo@chromium.org
Bug: chromium:595206
Change-Id: I030fdb3a80074ca6edd4749f86b39b590776ae6f
Reviewed-on: https://chromium-review.googlesource.com/c/1310056
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57181}
JSON format does not support \xNN encoding. Use \uNNNN instead.
+ Add myself to the src/tracing/OWNERS
BUG=chromium:895974
Change-Id: I410a09d44af08b61837579fa09d263d897b9385e
Reviewed-on: https://chromium-review.googlesource.com/c/1303535
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57180}
This reverts commit 9392727982.
Reason for revert: Speculative revert, seems the most probable cause of
https://bugs.chromium.org/p/v8/issues/detail?id=8396
Revert "[ubsan] More Object** replacements"
This reverts commit 5cce694d60.
Speculative revert.
NOTRY=true
Bug: v8:8396
Change-Id: I9c2866a9db707cd03e4cf90822acde20813cebf0
Reviewed-on: https://chromium-review.googlesource.com/c/1309761
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57174}
In addition (and in combination), try statements now support "catch"
clauses at the end that catch JavaScript exceptions throw by any builtin
or runtime function contained in the try block:
try {
ThrowTypeError(context, ...);
}
catch (e) {
// e has type Object
}
Bug: v8:7793
Change-Id: Ie285ff888c49c112276240f7360f70c8b540ed19
Reviewed-on: https://chromium-review.googlesource.com/c/1302055
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57169}
Now that lazy deserialization has been removed, we can roll back all
the mechanisms we introduced to support lazy single-builtin
deserialization.
This CL moves serialized builtin code objects (i.e.
off-heap-trampolines in most cases) back into the startup snapshot.
Support classes for builtin serialization and deserialization, as well
as the builtins snapshot itself are removed. Templatization on the
allocator class is removed as well.
Tbr: delphick@chromium.org
Bug: v8:6666, v8:7990
Change-Id: I2a910f8d3278b7e27b5f18ad408361ebd18871cc
Reviewed-on: https://chromium-review.googlesource.com/c/1304539
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57160}
CanCover is not transitive. The counter example are Nodes A,B,C such
that CanCover(A, B) and CanCover(B,C) and B is pure. In this case the
effect level of A and B might differ.
This CL adds a missing CanCover check to a case of shift reduction where
we assumed transitivity.
Change-Id: I9f368ffa6907d2af21bbc87b3e6570d0d422e125
Bug: v8:8384
Reviewed-on: https://chromium-review.googlesource.com/c/1307419
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57157}
This patch adds a micro-benchmark comparing Array#indexOf,
Array#includes, and a roughly equivalent `for` loop.
The benchmark can be used to measure any Array#{indexOf,includes}
optimizations we implement in the future.
Test:
tools/run_perf.py --binary-override-path=out/x64.release/d8 \
--filter=JSTests/ArrayIndexOfIncludesPolymorphic \
--extra-flags=--trace-turbo test/js-perf-test/JSTests.json
Bug: v8:8388
Change-Id: I9150d3e56e9d4cb2ffe6baa50ee8cddf8df0ac74
Reviewed-on: https://chromium-review.googlesource.com/c/1307430
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57156}
mostly in HandleScopeImplementer and related classes.
Bug: v8:3770
Change-Id: I9da757c60be99434b711fe74a5f5d296a0f08b22
Reviewed-on: https://chromium-review.googlesource.com/c/1300854
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57154}
as part of the continuing quest to get rid of Object*/Object** entirely.
Since it fits nicely, this CL as a bonus includes the planned change to
make Handle::location() return an Address*, in the process dropping the
temporarily needed duplicate Handle::location_as_address_ptr().
Bug: v8:3770
Change-Id: I87480289ce2a62ea1ae503e73d179256b7108c5c
Reviewed-on: https://chromium-review.googlesource.com/c/1298389
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57153}
- introduced ValueMirror interface, this interface contains methods to generate
different protocol entities,
- introduced DebugPropertyIterator, this iterator iterates through object properties
in the following order: exotic indices, enumerable strings, all other properties,
- removed all injected script infra, e.g. closure compiler,
R=dgozman@chromium.orgTBR=yangguo@chromium.org
Bug: chromium:595206
Change-Id: Idcfc04489ee52e015ad1d1d191c3474cc65e63f2
Reviewed-on: https://chromium-review.googlesource.com/c/1308353
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57150}
We didn't check if the input typed array was neutered before going to
the fast path, so we hit a CHECK in this case.
Fix this by just checking if the buffer was neutered and then going to
the 'check iterator' case if it is. This will cause a TypeError via
IterableToList, which was the same as the behavior before the
optmization was landed.
Bug: chromium:899519
Change-Id: I09e6389ea2ab1e3bef01e616721b48a9b66c1b2a
Reviewed-on: https://chromium-review.googlesource.com/c/1307422
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57137}
to control how the memory for Isolate object is allocated.
This is the support for pointer-compression friendly heap layout.
Bug: v8:8182
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Ida36b81ee22bd865005c394748b62d4c0897d746
Reviewed-on: https://chromium-review.googlesource.com/c/1251548
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57131}
Speculatively mitigation for renderer hangs in Scavenger
while waiting in a barrier.
Bug:
Change-Id: I48520e0ffd99123dbe352d2012c911186c187e4b
Reviewed-on: https://chromium-review.googlesource.com/c/1296463
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57130}
For memory limit checks, we should use the minimum of the
--wasm-max-mem-pages flag and kV8MaxWasmMemoryPages. The former is a
limit set by the user, the latter is the maximum we can handle
internally.
R=titzer@chromium.org
Bug: chromium:898677
Change-Id: I3c549f4e90dd016b5d07475d9353f30134f76dcc
Reviewed-on: https://chromium-review.googlesource.com/c/1305274
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57127}
This is a reland of bf3d7b9ae3
Original change's description:
> [wasm] Store compile errors in CompilationState
>
> We are currently storing compilation errors in the individual
> compilation units and pass it to the ErrorThrower during finishing.
> This CL changes that to store errors on the CompilationState directly.
> From there, it is propagated to the ErrorThrower in the compilation
> state callback.
> This removes more work from the finisher task and slims down the
> WasmCompilationUnits.
>
> R=mstarzinger@chromium.org
>
> Bug: v8:8343, v8:7921
> Change-Id: Id332add43d4219d2a30fee653ed4e53a9b2698d9
> Reviewed-on: https://chromium-review.googlesource.com/c/1303720
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57091}
Bug: v8:8343, v8:7921
Change-Id: Iaa5c89d224cb2bcfca2d12eba305413a9ad95618
Reviewed-on: https://chromium-review.googlesource.com/c/1304547
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57126}
BinaryNumberOpTyper was not monotonic: if one input changes
from Number to Numeric, while the other input stays BigInt,
the result would change from Number to BigInt.
We have some fuzzing tests for monotonicity but unfortunately
they never generated the inputs required for triggering this bug.
We'll look into improving our tests.
Bug: v8:8380
Change-Id: I7320d9ae4b89ad8798bf9e97cc272edba2162a77
Reviewed-on: https://chromium-review.googlesource.com/c/1307418
Commit-Queue: Hai Dang <dhai@google.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57125}
This is the V8 side of the implementation. You can take a look at a
prototype of the Chrome side changes in https://crrev.com/c/1273043.
Chrome could also use V8's default implementation of the trap handler,
see https://crrev.com/c/1290952.
Bug: v8:6743
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I9bb3e717db17a4f30bbb8acfd80a1f6510d463ff
Reviewed-on: https://chromium-review.googlesource.com/c/1283111
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57117}
These tests rely on dropping references to objects either explicitly ("o =
null;") or implicitly ("o goes out of scope") and then doing gc. It's essential
that we haven't already marked the WeakCell pointing to o and marked it alive
before dropping the reference.
BUG=v8:8179
Change-Id: Ie0b73f05c4baa937cf6f28325454ff9087a71a2c
Reviewed-on: https://chromium-review.googlesource.com/c/1306437
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57115}
If a caller starts the sampling heap profiler and takes a snapshot, and
then deletes the snapshot before the sampling has completed, a
use-after-free will occur on the StringsStorage pointer.
The same issue applies for StartTrackingHeapObjects which shares the
same StringsStorage object.
Bug: v8:8373
Change-Id: I5d69d60d3f9465f9dd3b3bef107c204e0fda0643
Reviewed-on: https://chromium-review.googlesource.com/c/1301477
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57114}
This adds appropriate LoopExit nodes for the JSCallReducer lowerings of
the following higher order Array builtins:
- Array.prototype.every()
- Array.prototype.find()
- Array.prototype.findIndex()
- Array.prototype.some()
Loop peeling allows TurboFan to make loop invariant operations in the
callback passed to the higher order builtin fully redundant, and thus
completely eliminate the loop invariant code from the subsequent loop
iterations. This can have a huge performance impact, depending on what
kind of code runs inside of the callback. For example, on the micro-
benchmarks outlined in http://crbug.com/v8/8273 we go from
forLoop: 364 ms.
every: 443 ms.
some: 432 ms.
find: 522 ms.
findIndex: 437 ms.
to
forLoop: 369 ms.
every: 354 ms.
some: 348 ms.
find: 419 ms.
findIndex: 360 ms.
which is 20% improvement, and essentially brings the Array builtins (the
appropriate ones Array#some() and Array#every() in this case) on par
with the hand-written `for`-loop.
Bug: v8:1956, v8:8273
Change-Id: I9d32736e5402807b4ac79cd5ad15ceacd1945681
Reviewed-on: https://chromium-review.googlesource.com/c/1305935
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57110}
and use Mixin pattern with linear inheritance instead. This will
allow to customize the way the Isolate is created.
Bug: v8:8238
Change-Id: Ic611df123653af3a0f2271394387492e440b5ea8
Reviewed-on: https://chromium-review.googlesource.com/c/1306433
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57106}
In Chromium tree, ICU is rolled to 63.1. And, auto-roller will soon
try to roll ICU in v8 to 63.1. Due to a nodejs trybot issue,
autoroll needs a manual intervention. In the meantime, this CL
will get rid of other blocking issues for ICU update.
Prepare for the ICU roll by revising test/intl as following:
* Line breaking loose mode is now supported in the
Chromium's copy of ICU. Adjust the test expectation.
* ICU's uloc_* can handle overlong locale ids. Drop tests
that are not valid any more.
Once ICU is rolled, a couple of TSAN-suppressed tests can
be unsuppressed, but that has to be done in a separate CL.
Bug: chromium:893196,v8:8272, v8:8110
Test: intl/*, test262/test402/*
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I17f11457b61376b1e8d41bbbc951fa6cd3355a54
Reviewed-on: https://chromium-review.googlesource.com/c/1289369
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57105}
This introduces Word64 support for the CheckBounds operator, which now
lowers to either CheckedUint32Bounds or CheckedUint64Bounds after the
representation selection. The right hand side of CheckBounds can now
be any positive safe integer on 64-bit architectures, whereas it remains
Unsigned31 for 32-bit architectures. We only use the extended Word64
support when the right hand side is outside the Unsigned31 range, so
for everything except DataViews this means that the performance should
remain the same. The typing rule for the CheckBounds operator was
updated to reflect this new behavior.
The CheckBounds with a right hand side outside the Unsigned31 range will
pass a new Signed64 feedback kind, which is handled with newly introduced
CheckedFloat64ToInt64 and CheckedTaggedToInt64 operators in representation
selection.
The JSCallReducer lowering for DataView getType()/setType() methods was
updated to not smi-check the [[ByteLength]] and [[ByteOffset]] anymore,
but instead just use the raw uintptr_t values and operate on any value
(for 64-bit architectures these fields can hold any positive safe
integer, for 32-bit architectures it's limited to Unsigned31 range as
before). This means that V8 can now handle huge DataViews fully, without
falling off a performance cliff.
This refactoring even gave us some performance improvements, on a simple
micro-benchmark just exercising different DataView accesses we go from
testDataViewGetUint8: 796 ms.
testDataViewGetUint16: 997 ms.
testDataViewGetInt32: 994 ms.
testDataViewGetFloat64: 997 ms.
to
testDataViewGetUint8: 895 ms.
testDataViewGetUint16: 889 ms.
testDataViewGetInt32: 888 ms.
testDataViewGetFloat64: 890 ms.
meaning we lost around 10% on the single byte case, but gained 10% across
the board for all the other element sizes.
Design-Document: http://bit.ly/turbofan-word64
Bug: chromium:225811, v8:4153, v8:7881, v8:8171, v8:8383
Change-Id: Ic9d1bf152e47802c04dcfd679372e5c85e4abc83
Reviewed-on: https://chromium-review.googlesource.com/c/1303732
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57095}
This reverts commit bf3d7b9ae3.
Reason for revert: Breaks TSAN build, see
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20TSAN/23248
Original change's description:
> [wasm] Store compile errors in CompilationState
>
> We are currently storing compilation errors in the individual
> compilation units and pass it to the ErrorThrower during finishing.
> This CL changes that to store errors on the CompilationState directly.
> From there, it is propagated to the ErrorThrower in the compilation
> state callback.
> This removes more work from the finisher task and slims down the
> WasmCompilationUnits.
>
> R=mstarzinger@chromium.org
>
> Bug: v8:8343, v8:7921
> Change-Id: Id332add43d4219d2a30fee653ed4e53a9b2698d9
> Reviewed-on: https://chromium-review.googlesource.com/c/1303720
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57091}
TBR=mstarzinger@chromium.org,clemensh@chromium.org
Change-Id: Id32c7337494a4749485adbcfcaae7b2331afea66
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8343, v8:7921
Reviewed-on: https://chromium-review.googlesource.com/c/1304544
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57094}
We are currently storing compilation errors in the individual
compilation units and pass it to the ErrorThrower during finishing.
This CL changes that to store errors on the CompilationState directly.
From there, it is propagated to the ErrorThrower in the compilation
state callback.
This removes more work from the finisher task and slims down the
WasmCompilationUnits.
R=mstarzinger@chromium.org
Bug: v8:8343, v8:7921
Change-Id: Id332add43d4219d2a30fee653ed4e53a9b2698d9
Reviewed-on: https://chromium-review.googlesource.com/c/1303720
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57091}
For NumberMin and NumberMax we don't need to go to Float64 when the
inputs are known to be in SafeInteger range, instead we can go to
Word64 on 64-bit architectures. This is preliminary work for the
huge DataView support, since we'll utilize NumberMax in that case
to clamp the limit for the bounds check.
Bug: v8:8178, v8:8383
Change-Id: I414114229c5c86b92749d30d645cedc641541ae4
Reviewed-on: https://chromium-review.googlesource.com/c/1304535
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57090}
The "grow_memory" opcode was renamed to "memory.grow", and the spec
repo was updated to use kExprMemoryGrow internally instead of
kExprGrowMemory (https://github.com/WebAssembly/spec/pull/720).
This CL does the same change for v8.
Drive-by: Rename "current_size" to "memory.size", and a minor cleanup
in wasm-graph-builder.js to bring it in line with the version in the
js-api tests in the spec repo.
R=titzer@chromium.org
Change-Id: If525dba898b2c248890a616d3392c22b45f698ef
Reviewed-on: https://chromium-review.googlesource.com/c/1302057
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57089}
This fixes the fall-back case when parsing a multiplicative expression
where the lookahead found a '-' token followed by an unsigned token, but
no '*' token is following. We cannot rewind both tokens, but still need
to make sure that a full multiplicative expression is parsed.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-8377
BUG=v8:8377
Change-Id: I20ce6267445b32bdaf03f41f11d9ef4be66cb636
Reviewed-on: https://chromium-review.googlesource.com/c/1304317
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57084}
The Counters are not specific to compilation units, they just happen to
be used in WasmCompilationUnit::ExecuteCompilation.
Remove it from the compilation unit and pass it explicitly where needed.
This saves another field on the compilation units.
R=titzer@chromium.org
Bug: v8:8343
Change-Id: Iad4fd8ae23b022c237535503e0e805db7e67071a
Reviewed-on: https://chromium-review.googlesource.com/c/1304297
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57083}
- Store dirty JSWeakFactories in a heap root (not native context) -
during GC there's no native context necessarily.
- Schedule one microtask per JSWeakFactory.
- Enter the context of the cleanup function before calling it.
BUG=v8:8179
Change-Id: Icaa245a08a60dd7325af828858ebe55d842c5bf6
Reviewed-on: https://chromium-review.googlesource.com/c/1298899
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57081}
This allows very large arrays being joined to incrementally,
on-demand allocate the internal buffer. Previously, join
would allocate the buffer upfront and all at once. Large,
sparse arrays will use less memory.
Bug: chromium:897404
Change-Id: Id914b14a7c55a62834f63ad602bdb45363249075
Reviewed-on: https://chromium-review.googlesource.com/c/1303538
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57075}
Now that embedded builtins are enabled everywhere*, lazy
deserialization can be turned off and removed.
* Except nosnap builds, on aix and in msvc builds.
Bug: v8:6666, v8:6624, v8:7990
Change-Id: Ib5fefe10e7ff35b13a1eb803fbc3736b8851b22b
Reviewed-on: https://chromium-review.googlesource.com/c/1288638
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57064}
While not strictly necessary, this is consistent with how
SlowFlagGetter behaves. It adds an additional shift operation (which
we could fold into the smi untagging if needed).
Drive-by: Typify flag accessors.
Bug: chromium:899464
Change-Id: Ib154d626e522ed723e2c19b1ab7f68560ac414bc
Reviewed-on: https://chromium-review.googlesource.com/c/1304315
Reviewed-by: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57063}
When replacing a LoadElement with variable index with its known fields,
only do it if the types match, otherwise we end up with a graph that
representation selection cannot handle. That can only happen in dead
code, but TurboFan would nevertheless crash in representation selection.
Bug: chromium:893982, chromium:899524, v8:5267, v8:6200
Change-Id: I01e645d5e01bffb911d216d37d923792d9d0beab
Reviewed-on: https://chromium-review.googlesource.com/c/1303721
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57059}
In order for Error.prepareStackTrace() to be able to reconstruct the
same stack frame that the internal mechanism can, we need to also
expose the index for the Promise.all() builtin. The newly added
CallSite#getPromiseIndex() does exactly that.
Bug: v8:7522
Change-Id: I904a4c1005f539536a71926ea1da38b31e2a2e8a
Reviewed-on: https://chromium-review.googlesource.com/c/1304293
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57055}
This is a reland of 9cde880856 now the the underlying
problem in Chromium is fixed by:
https://chromium-review.googlesource.com/c/chromium/src/+/1301459
Original change's description:
> [Compile] Ensure we don't access the native context during bytecode finalization.
>
> 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}
TBR=leszeks@chromium.org
Bug: chromium:898076, v8:8041
Change-Id: I11904e19e843b0eadab698196ac1ef9c7aeec766
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel; luci.chromium.try:linux_chromium_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/1301480
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57048}
In order to ensure that Isolate::New()/Isolate::Delete() are the bottlenecks
this CL also makes the Isolate class final.
Bug: v8:8182
Change-Id: I6bb170363a1210f66d63f4bcc46ea06fb5000d50
Reviewed-on: https://chromium-review.googlesource.com/c/1301481
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57041}
The assumption behind this optimization was invalid. Even if the
string's prototype is unchanged, the symbol could exist somewhere
further up the prototype chain.
GetProperty has been sped up significantly so it might be fine to just
skip this fast path. An alternative would be to use a protector cell.
Bug: v8:8357
Change-Id: Ia577107a58157350eb15780c02aa63d77e600637
Reviewed-on: https://chromium-review.googlesource.com/c/1301498
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57038}
and also move embedder fields from Isolate to IsolateData.
The external memory counter fields are temporarily moved to IsolateData in
order to avoid unexpected Node JS bot failures which happen if the fields
are left in the Heap class.
Bug: v8:8182
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I9d58f235c0ce40e110f595addd03b80b3617aa77
Reviewed-on: https://chromium-review.googlesource.com/c/1278793
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57037}
This just adds calls to SerializePrototype right before we access the
serialized prototype. Eventually we need to do this earlier.
Bug: v8:7790, chromium:899115
Change-Id: I597e95f5f6df8aae608ee295fe9550e7c2a45e6d
Reviewed-on: https://chromium-review.googlesource.com/c/1301475
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57034}
This CL refactors the existing trap handler code for Linux to allow a
cleaner extension to Windows.
1) The CL extracts platform-specific code into separate files, see
https://docs.google.com/document/d/1HCgKIpdjy_CEodTLvZ5VuykDI6gGTHrTtau2j0zwm28.
Specifically this means:
* Move posix-specific API functions from v8.h to v8-wasm-trap-handler-posix.h.
Deprecate the existing TryHandleSignal API function.
* Move posix-specific function declarations from trap-handler-internal.h to
handler-inside-posix.h
* Move posix-specific function definitions from handler-shared.cc to
handler-outside-posix.cc
2) The CL changes filenames from *-linux.* to *-posix.*. I expect that
most of the implementation for MacOS will be the same as for Linux.
Bug: v8:6743
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I4bb7f199564a2f01042084d15a82311d11a93c7b
Reviewed-on: https://chromium-review.googlesource.com/c/1280324
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57028}
The valid store types of a {Float64Array} heap view are specified to be
"float?" and "double?". We correctly accepted both types but forgot to
emit the appropriate conversion in the "float?" case. This just adds the
missing conversion expression.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-crbug-898974
BUG=chromium:898974,v8:8347
Change-Id: I306b10e2088185b1522da29b1a113908ef9925f2
Reviewed-on: https://chromium-review.googlesource.com/c/1301499
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57025}
This adds support for Promise.all() to --async-stack-traces (also at
zero cost, since we can derive the relevant information from the resolve
element closure and context). In case of `Promise.all(a)` the stack
trace even tells you which element of `a` is responsible, for example
```js
async function fine() {}
async function thrower() { await fine(); throw new Error(); }
async function test() { await Promise.all([fine(), thrower()]); }
```
will generate the following stack trace
```
Error
at thrower (something.js:1:9)
at async Promise.all (index 1)
at async test (something.js:3:3)
```
so it not only shows the async Promise.all() frames, but even tells the
user exactly that the second element of `[fine(), thrower()]` is the
relevant one.
Bug: v8:7522
Change-Id: I279a845888e06053cf0e3c9338ab71caabaabf45
Reviewed-on: https://chromium-review.googlesource.com/c/1299248
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57023}
Currently, because the source float_64_array has an iterator, it hits
the code in the "check_iterator" section of TypedArrayFrom which calls
IterableToList. This builds a temporary PACKED_ELEMENTS array (and boxes
all of the numeric values as HeapNumbers), then uses this as the source
array.
This patch checks if the source array is a TypedArray, and if the iterator
is the built-in one (where we know the iterator's behaviour). If both are
true then it bypasses the creation of this temporary array and uses the
original TypedArray as the source.
This allows it to take advantage of the existing fast code for copying one
typed array to another.
R=hablich@chromium.org, petermarshall@chromium.org
Bug: chromium:884671
Change-Id: I19a944c9d6d5d07699c7dc3ad7196fc871200b62
Reviewed-on: https://chromium-review.googlesource.com/c/1297312
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57022}
This test was incidentally fixed by
https://chromium-review.googlesource.com/c/v8/v8/+/1280436.
Calls to StartTickSample() and FinishTickSample() are not permitted by
multiple producers. If the signal handler interrupts the main thread,
both might receive the same pointer into the circular buffer and one
will overwrite the data of the other.
This means we cannot call it in tests, and have to use AddSample()
instead.
Bug: v8:8209
Change-Id: I6904204e88077f704f819b52cde0fdaab0f13462
Reviewed-on: https://chromium-review.googlesource.com/c/1299022
Reviewed-by: Alexei Filippov <alph@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57019}
This CL restores consistency with other platforms. ebx is now the
kRootRegister on ia32, and thus not an allocatable register any more.
The PreserveRootIA32 register configuration can be removed since it is
now identical to the Default configuration.
Bug: v8:6666
Change-Id: If4e2b4c52aa8b5db40bcd3b4469004b29c0e3d99
Reviewed-on: https://chromium-review.googlesource.com/c/1299078
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57018}
This skips big-object-literal on bots with dchecks (setting DEBUG) and with
stress mode in general.
NOTRY=true
Bug: v8:8328
Change-Id: I53480d1ee942d2c83e46c8804bd8920a5e36cad2
Reviewed-on: https://chromium-review.googlesource.com/c/1301495
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57017}
Checking impl()->IsAsync(identifier) is insufficient since it could be
parenthesized. By checking the token in addition to IsIdentifier guarantees
that we've only seen the single token ASYNC.
Bug: chromium:898812
Change-Id: Id94dd607381050b4bd8cd6d8672a5d11256db7da
Reviewed-on: https://chromium-review.googlesource.com/c/1300134
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57013}
This CL applies the equivalent of the Object -> ObjectPtr
transformation to MaybeObject and HeapObjectReference. We
need no renaming in this case because we can just migrate
them both in one go.
Bug: v8:3770
Change-Id: Ie1259c3e8c556eff00f8bcf534d7270ca9fe00e1
Reviewed-on: https://chromium-review.googlesource.com/c/1298386
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57010}
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}
