- 03 Nov, 2017 2 commits
-
-
Benedikt Meurer authored
This extends the support in TurboFan and the ICs for OOB loads to also apply to typed arrays and receivers whose prototype chain is protected by the "no elements" protector (aka the Array protector). TurboFan will generate code to materialize undefined instead when it sees a load that has the OOB bit set and add an appropriate code dependency on the global protector. For typed arrays it doesn't even need to check the global protector since elements are never looked up in the prototype chain for typed arrays. In the simple micro-benchmark from the bug we go from testInBounds: 103 ms. testOutOfBounds: 289 ms. to testInBounds: 103 ms. testOutOfBounds: 102 ms. which fixes the 3x slowdown and thus addresses the performance cliff. In general it's still beneficial to make sure that you don't access out of bounds, especially once we introduce a bounds check elimination pass to TurboFan. This also seems to improve the jQuery benchmark on the Speedometer test suite by like 1-2% on average. And the SixSpeed rest benchmarks go from rest-es5: 25 ms. rest-es6: 23 ms. to rest-es5: 6 ms. rest-es6: 4 ms. so a solid 5.7x improvement there. Bug: v8:6936, v8:7014, v8:7027 Change-Id: Ie99699c69cc40057512e72fd40ae28107216c423 Reviewed-on: https://chromium-review.googlesource.com/750089 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#49095}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/ec29950..53fa255 Rolling v8/buildtools: https://chromium.googlesource.com/chromium/buildtools/+log/3275a09..df36429 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/1471560..7208715 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/4ea1d22..9f0284f Rolling v8/tools/swarming_client: https://chromium.googlesource.com/infra/luci/client-py/+log/fe94e72..5da404c TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: I837c1aa249d66b24733fbfbef597df6fd5480e6e Reviewed-on: https://chromium-review.googlesource.com/752881Reviewed-by:
v8 autoroll <v8-autoroll@chromium.org> Commit-Queue: v8 autoroll <v8-autoroll@chromium.org> Cr-Commit-Position: refs/heads/master@{#49094}
-
- 02 Nov, 2017 27 commits
-
-
Benedikt Meurer authored
This turns on the existing --internalize_on_the_fly flag for the MEGAMORPHIC KeyedLoadIC to properly internalize strings before looking up the property. This avoids the otherwise taken runtime call to %KeyedGetProperty, which is definitely slower. Initially the --internalize_on_the_fly flag was turned off because internalizing strings on the fly causes too much traffic on the megamorphic stub cache. We avoid this problem here by not probing the stub cache in that case, which still gives the benefit of not having to go to the runtime. This improves the babylon test on the web-tooling-benchmark by around 2-3% and will probably also help with several tests (like React or Ember) on the Speedometer benchmark. If this CL causes trouble (i.e. tanks something important), we can just turn off the --internalize_on_the_fly flag again. Bug: v8:6936, v8:7026 Change-Id: If295ed3fd013f8b0ff031f9979e7df21dab817b6 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Reviewed-on: https://chromium-review.googlesource.com/751464Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#49093}
-
Michael Lippautz authored
Sweeping a page while currently scavenging it is broken as the scavenger might override the slot it is currently processing. Bug: chromium:779503 Change-Id: I224a144b84e97a956bf10ba018132c2713e8f78d Reviewed-on: https://chromium-review.googlesource.com/752081 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#49092}
-
Alexei Filippov authored
No more crashes are seen in the RuntimeCallStats::Leave function. So we can remove the debug info. BUG=chromium:760649 Change-Id: If0a5f4ebf9ae359e3b8180ef2f8d37cab8659b06 Reviewed-on: https://chromium-review.googlesource.com/747483Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#49091}
-
Ulan Degenbaev authored
This is a reland of a9a50dc9 Buildbot crashes are fixed by a274fc65. Original change's description: > [heap] Temporarily disable concurrent marking. > > The 6.3 branch has a data race that is fixed in 6.4 but the fix is too > large for back merging. > > This CL will be back-merged to 6.3 after getting Canary coverage. > > Concurrent marking will be re-enabled afterwards. > > Bug: chromium:774644 > Change-Id: I4112da0e133a637cc4fb52dee2e4c165cdc74f1f > Reviewed-on: https://chromium-review.googlesource.com/749811 > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49080} Bug: chromium:774644 Change-Id: Idf5d179eca25a1481c70c6ca3bccde4869deb544 Reviewed-on: https://chromium-review.googlesource.com/751271Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#49090}
-
Michal Majewski authored
Bug: v8:6917 Change-Id: Ia80de1d0430efb0c5f41a79267ba9146c5be42ce Reviewed-on: https://chromium-review.googlesource.com/751462 Commit-Queue: Michał Majewski <majeski@google.com> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#49089}
-
Benedikt Meurer authored
Reduce code duplication, which breaks jumbo builds. Put the StrictEqual typing rule into the OperationTyper and share the JSType function, which is also used by SameValue. Bug: chromium:779531 Change-Id: If292f319217286fd1c676be04f9de3925ed56965 Reviewed-on: https://chromium-review.googlesource.com/751665Reviewed-by:
-
Ulan Degenbaev authored
During iteration of the optimized code list to process weak slots, we need to clear the next_code_link in the CodeDataContainer of a dying code object because the CodeDataContainer can still be alive. BUG=v8:6792 Change-Id: Iec5f7430a4097cb622de2157bdec2a7d539dbba0 Reviewed-on: https://chromium-review.googlesource.com/751663Reviewed-by:
-
Michael Lippautz authored
Phantom handles were processed at the same time as finalizers. This meant that if a finalizer kept an object alive the phantom handle was still destroyed. This becomes a problem in the context of Blink GCs where internal fields are roots for Blink. Prematurely destroying a phantom handle can lead to stale pointers. Bug: chromium:772299 Change-Id: If02365c457be8ce48379ad357cce36baa9617cfb Reviewed-on: https://chromium-review.googlesource.com/750625Reviewed-by:
-
Michal Majewski authored
Bug: v8:6917 Change-Id: I95355d445ae08a500a3210314dc893dfaddf209d Reviewed-on: https://chromium-review.googlesource.com/750808Reviewed-by:
-
Mircea Trofin authored
We expect no GC between the call to UnwindAndFindHandler and the call to that handler. We can precalculate the handler entrypoint and then let the CEntryStub just load and call that address. The main motivation for this change is the wasm on the native heap work, and making the CEntryStub able to work with non- Code* values. Bug: v8:6876 Change-Id: I660f29619edc315afbb537ef3df018865fab7ba4 Reviewed-on: https://chromium-review.googlesource.com/744723 Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Reviewed-by:
Brad Nelson <bradnelson@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#49084}
-
Ulan Degenbaev authored
This reverts commit a9a50dc9. Reason for revert: buildbot crashes. Original change's description: > [heap] Temporarily disable concurrent marking. > > The 6.3 branch has a data race that is fixed in 6.4 but the fix is too > large for back merging. > > This CL will be back-merged to 6.3 after getting Canary coverage. > > Concurrent marking will be re-enabled afterwards. > > Bug: chromium:774644 > Change-Id: I4112da0e133a637cc4fb52dee2e4c165cdc74f1f > Reviewed-on: https://chromium-review.googlesource.com/749811 > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49080} TBR=ulan@chromium.org,hpayer@chromium.org,mlippautz@chromium.org Change-Id: Ia9d2128c01b811073c1c8f0392eb13b7d7745cd1 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:774644 Reviewed-on: https://chromium-review.googlesource.com/751501Reviewed-by:
-
Clemens Hammacher authored
After renaming the WasmExecutionMode constants, I should also have renamed the tests generated from the WASM_EXEC_TEST macro. This CL cleans this up. R=titzer@chromium.org Change-Id: Ifcb1a1e09422a06f89c3b44dc6b7799d3f84f7ac Reviewed-on: https://chromium-review.googlesource.com/744044 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#49082}
-
Toon Verwaest authored
Bug: chromium:779367 Change-Id: I0d361ffc9be1e271e91ce81c3e5cf70697c0ac0b Reviewed-on: https://chromium-review.googlesource.com/749812Reviewed-by:
-
Ulan Degenbaev authored
The 6.3 branch has a data race that is fixed in 6.4 but the fix is too large for back merging. This CL will be back-merged to 6.3 after getting Canary coverage. Concurrent marking will be re-enabled afterwards. Bug: chromium:774644 Change-Id: I4112da0e133a637cc4fb52dee2e4c165cdc74f1f Reviewed-on: https://chromium-review.googlesource.com/749811Reviewed-by:
-
Jakob Gruber authored
Abort execution on stack overflow during compilation if --abort-on-stack-or-string-length-overflow was passed (for correctness fuzzer support). Bug: chromium:778962 Change-Id: Idd50b47c4ddc03b7839ce850da95502fce4cc848 Reviewed-on: https://chromium-review.googlesource.com/750842Reviewed-by:
-
Michal Majewski authored
This is a reland of 697b2c09 Original change's description: > Setting up the environment for testrunner refactored > > Bug: v8:6917 > Change-Id: Ibc3c738ef807d37d8b76f440d9765c4d0405c021 > Reviewed-on: https://chromium-review.googlesource.com/735421 > Commit-Queue: Michał Majewski <majeski@google.com> > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48923} Bug: v8:6917 Change-Id: I07918814ee8277eca96bcb2d330e6b08f6a0505d Reviewed-on: https://chromium-review.googlesource.com/741621Reviewed-by:
-
Michael Achenbach authored
This reverts commit 6366a010. Reason for revert: Breaks layout tests: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/19429 Original change's description: > [ic] Internalize strings on the fly in KeyedLoadICGeneric. > > This turns on the existing --internalize_on_the_fly flag for the > MEGAMORPHIC KeyedLoadIC to properly internalize strings before > looking up the property. This avoids the otherwise taken runtime > call to %KeyedGetProperty, which is definitely slower. > > Initially the --internalize_on_the_fly flag was turned off because > internalizing strings on the fly causes too much traffic on the > megamorphic stub cache. We avoid this problem here by not probing > the stub cache in that case, which still gives the benefit of not > having to go to the runtime. > > This improves the babylon test on the web-tooling-benchmark by around > 2-3% and will probably also help with several tests (like React or > Ember) on the Speedometer benchmark. > > If this CL causes trouble (i.e. tanks something important), we can > just turn off the --internalize_on_the_fly flag again. > > Bug: v8:6936, v8:7026 > Change-Id: Ia59a8a3799d9624d831d66b05bae3ecef31cee0a > Reviewed-on: https://chromium-review.googlesource.com/750821 > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49072} TBR=ishell@chromium.org,bmeurer@chromium.org Change-Id: I5345eb29016ecd6b7788b1b49b2f53992ea82b58 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6936, v8:7026 Reviewed-on: https://chromium-review.googlesource.com/750904Reviewed-by:
-
peterwmwong authored
- Add WeakMapPrototypeDelete and WeakSetPrototypeDelete TFJ builtins - Fast paths when it's not necessary to shrink the table - Add WeakCollectionDelete TFS Some quick benchmarks shows 1.4x - 2.15x gains in performance. https://github.com/peterwmwong/v8-perf/blob/master/weakcollection-delete/README.md Bug: v8:5049, v8:6604 Change-Id: I14036df153f3a0242f9083d751658b868b16660a Reviewed-on: https://chromium-review.googlesource.com/743864Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#49076}
-
Michael Achenbach authored
This reverts commit 1feadfe8. Reason for revert: Reland as bot stayed red after revert. Original change's description: > Revert "[cctest] Clarify that tests for sync instructions are simulator specific" > > This reverts commit 4013518f. > > Reason for revert: > https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20gc%20stress > > Original change's description: > > [cctest] Clarify that tests for sync instructions are simulator specific > > > > Some tests were recently added to test-simulator-arm.cc, however this file is > > meant for tests that are specific to the simulator and therefore are not written > > to work on hardware. While this sounds surprising, the reason is that our simulation > > of synchronisation instructions is more conservative than on hardware. > > > > To make this more clear, this patch renames the "test-simulator-arm{,64}.cc" > > files to "test-sync-primitives-arm{,64}.cc", and moves the vneg and vabs tests > > into "test-assembler-arm.cc" which is were tests that are garanteed to work in > > either native or simulated environments live. > > > > Finally, take the opportunity to share a little bit of code. > > > > Bug: v8:6963 > > Change-Id: Ifb85d3671c823b9bba73d09f419536b089a4e87c > > Reviewed-on: https://chromium-review.googlesource.com/749387 > > Reviewed-by: Clemens Hammacher <clemensh@chromium.org> > > Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> > > Cr-Commit-Position: refs/heads/master@{#49073} > > TBR=clemensh@chromium.org,pierre.langlois@arm.com,bmeurer@chromium.org > > Change-Id: I1bfb4e9c7c18b716f417a84b18a14cb2e1fa3a7a > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: v8:6963 > Reviewed-on: https://chromium-review.googlesource.com/750624 > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Commit-Queue: Michael Achenbach <machenbach@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49074} TBR=machenbach@chromium.org,clemensh@chromium.org,pierre.langlois@arm.com,bmeurer@chromium.org Change-Id: I5af7bd3678758130534730a2f6f0b651b64c6956 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6963 Reviewed-on: https://chromium-review.googlesource.com/750903Reviewed-by:
-
Michael Achenbach authored
This reverts commit 4013518f. Reason for revert: https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20gc%20stress Original change's description: > [cctest] Clarify that tests for sync instructions are simulator specific > > Some tests were recently added to test-simulator-arm.cc, however this file is > meant for tests that are specific to the simulator and therefore are not written > to work on hardware. While this sounds surprising, the reason is that our simulation > of synchronisation instructions is more conservative than on hardware. > > To make this more clear, this patch renames the "test-simulator-arm{,64}.cc" > files to "test-sync-primitives-arm{,64}.cc", and moves the vneg and vabs tests > into "test-assembler-arm.cc" which is were tests that are garanteed to work in > either native or simulated environments live. > > Finally, take the opportunity to share a little bit of code. > > Bug: v8:6963 > Change-Id: Ifb85d3671c823b9bba73d09f419536b089a4e87c > Reviewed-on: https://chromium-review.googlesource.com/749387 > Reviewed-by: Clemens Hammacher <clemensh@chromium.org> > Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> > Cr-Commit-Position: refs/heads/master@{#49073} TBR=clemensh@chromium.org,pierre.langlois@arm.com,bmeurer@chromium.org Change-Id: I1bfb4e9c7c18b716f417a84b18a14cb2e1fa3a7a No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6963 Reviewed-on: https://chromium-review.googlesource.com/750624Reviewed-by:
-
Pierre Langlois authored
Some tests were recently added to test-simulator-arm.cc, however this file is meant for tests that are specific to the simulator and therefore are not written to work on hardware. While this sounds surprising, the reason is that our simulation of synchronisation instructions is more conservative than on hardware. To make this more clear, this patch renames the "test-simulator-arm{,64}.cc" files to "test-sync-primitives-arm{,64}.cc", and moves the vneg and vabs tests into "test-assembler-arm.cc" which is were tests that are garanteed to work in either native or simulated environments live. Finally, take the opportunity to share a little bit of code. Bug: v8:6963 Change-Id: Ifb85d3671c823b9bba73d09f419536b089a4e87c Reviewed-on: https://chromium-review.googlesource.com/749387Reviewed-by:Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> Cr-Commit-Position: refs/heads/master@{#49073}
-
Benedikt Meurer authored
This turns on the existing --internalize_on_the_fly flag for the MEGAMORPHIC KeyedLoadIC to properly internalize strings before looking up the property. This avoids the otherwise taken runtime call to %KeyedGetProperty, which is definitely slower. Initially the --internalize_on_the_fly flag was turned off because internalizing strings on the fly causes too much traffic on the megamorphic stub cache. We avoid this problem here by not probing the stub cache in that case, which still gives the benefit of not having to go to the runtime. This improves the babylon test on the web-tooling-benchmark by around 2-3% and will probably also help with several tests (like React or Ember) on the Speedometer benchmark. If this CL causes trouble (i.e. tanks something important), we can just turn off the --internalize_on_the_fly flag again. Bug: v8:6936, v8:7026 Change-Id: Ia59a8a3799d9624d831d66b05bae3ecef31cee0a Reviewed-on: https://chromium-review.googlesource.com/750821Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#49072}
-
Andreas Haas authored
The existing stack check only checked the number of stack frames on the stack, not the actual size of the stack frames. In the test case, each stack frame is huge, and the interpreter runs out of memory before the stack check stops the execution. With this change we take the size of the value stack and the size of the control stack and compare their sum to the stack limit of V8. Note that this stack limit is kind of arbitrary, because the stack space of the interpreter is not on the actual runtime stack but allocated in zone memory, and the stack check exists to simulate stack overflows in compiled code, not to prevent actual stack overflows. R=clemensh@chromium.org TEST=mjsunit/regress/wasm/regress-778917 Bug: chromium:778917 Change-Id: Ife47631fcb1a178a68facab1e42c0069b12c0155 Reviewed-on: https://chromium-review.googlesource.com/744003 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Benedikt Meurer authored
This is an experiment to quantify the impact of SlicedStrings on both performance and memory usage. The intention is to get Canary coverage for the experiment and then decide how to proceed. Bug: v8:7025 Change-Id: Ied548cd9e2fab127c1ad2aea3e60b2615d3de663 Reviewed-on: https://chromium-review.googlesource.com/750082 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#49070}
-
Yang Guo authored
Proxy's call trap can be used to cause recursion. R=bmeurer@chromium.org, tebbi@chromium.org Bug: chromium:779344 Change-Id: I19c989f618f7230028ebe18c3415bc3f4bd72b93 Reviewed-on: https://chromium-review.googlesource.com/743782Reviewed-by:
-
Benedikt Meurer authored
This partially reverts commit aaebbbaa, which removed the --string-slices flag. We reintroduce the flag as a build time flag for an experiment to gather information of how much SliceStrings help with throughput and effective memory use. Bug: v8:7025 Change-Id: I529da91bb7501fe93d83891abf560710f3ecb9d0 Reviewed-on: https://chromium-review.googlesource.com/750681Reviewed-by:
-
Benedikt Meurer authored
This CL adds support for two byte string comparisons to the StringEqual builtin, which so far was bailing out to the generic %StringEqual runtime function whenever any two-byte string was involved. This made comparisons that involved two-byte strings, either comparing them to one-byte strings or comparing two two-byte strings, up to 3x slower than if only one-byte strings were involved. With this change, all direct string (SeqString or ExternalString) equality checks are roughly on par now, and the weird performance cliff is gone. On the micro-benchmark from the bug we go from stringEqualBothOneByteSeqString: 162 ms. stringEqualTwoByteAndOneByteSeqString: 446 ms. stringEqualOneByteAndTwoByteSeqString: 438 ms. stringEqualBothTwoByteSeqString: 472 ms. to stringEqualBothOneByteSeqString: 151 ms. stringEqualTwoByteAndOneByteSeqString: 158 ms. stringEqualOneByteAndTwoByteSeqString: 166 ms. stringEqualBothTwoByteSeqString: 160 ms. which is the desired result. On the esprima test of the web-tooling-benchmark we seem to improve by 1-2%, which corresponds to the savings of going to the runtime for many StringEqual comparisons. Drive-by-cleanup: Introduce LoadAndUntagStringLength helper into the CSA with proper typing to avoid the unnecessary shifts on 64-bit platforms when keeping the length tagged initially in StringEqual. Bug: v8:4913, v8:6365, v8:6371, v8:6936, v8:7022 Change-Id: I566f4b80e217513775ffbd35e0480154abf59b27 Reviewed-on: https://chromium-review.googlesource.com/749223Reviewed-by:
-
- 01 Nov, 2017 5 commits
-
-
Hans Wennborg authored
Recent Clang versions (r317076+) warn about this. Bug: chromium:780523 Change-Id: Iccc8d675ce4700f67dedfaa60bc6662b03b55ceb Reviewed-on: https://chromium-review.googlesource.com/749117Reviewed-by:
-
Leszek Swirski authored
Rather than having a single script compilation timer, split it into multiple timers depending on the state of the (blink-owned) code cache and (v8-owned) complation cache. This is intended to replace both the script compilation time timer, and the compilation heuristic enum. Also keep track of why blink might not want us to produce (or consume) a code cache, and split the compilation timer on this as well. Note, there is currently no timer for streaming sources, so these won't show up in the histograms. Bug: chromium:582873 Bug: chromium:769203 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Ia32fff044f919e20e3cec73329e62e01e421b72a Reviewed-on: https://chromium-review.googlesource.com/746922 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#49065}
-
Michaël Zasso authored
See: https://github.com/nodejs/node-v8/issues/23 Bug: Change-Id: Id8e1e828f6f9b1639917319b88c037942f8e73e8 Reviewed-on: https://chromium-review.googlesource.com/743941Reviewed-by:
-
Martyn Capewell authored
Push cp in EnterFrame for CONSTRUCT type frames, in order to align the stack op, and adapt the users (Generate_JSBuiltinConstructStub*) to account for it. Then align the rest of the stack operations in Generate_JSBuiltinConstructStubHelper. Bug: v8:6644 Change-Id: I4ffca329d5838902f787a52ac0d362dfbf9174c6 Reviewed-on: https://chromium-review.googlesource.com/746923Reviewed-by:
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/7765787..ec29950 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/6fd9f08..1471560 TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: I229d22f43903bc9101ba0958b8f5a05f83700913 Reviewed-on: https://chromium-review.googlesource.com/748582Reviewed-by:
-
- 31 Oct, 2017 6 commits
-
-
Natalie Silvanovich authored
Change-Id: I7e833c3b06cfb3ff9eda663c2bee4981013744b0 Adding index accessor counter Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Ic353c11fa0f430537819387d17eedeec5466d9cc Bug: Reviewed-on: https://chromium-review.googlesource.com/741169Reviewed-by:
-
Junliang Yan authored
Bug: Change-Id: I72a91c3a7c89730b6f54ecd30743263ff0ab4642 Reviewed-on: https://chromium-review.googlesource.com/746946Reviewed-by:
-
Adam Klein authored
The parser now throws for literals that are too big for the runtime to support, thus avoiding CHECK-failures further down the line. Tbr: rmcilroy@chromium.org Bug: v8:6791 Change-Id: Ie45ddebb8aa9e7a30e8b6b74f99916b700e38e4a Reviewed-on: https://chromium-review.googlesource.com/747682 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
-
Mathias Bynens authored
Currently, dynamic `import()` throws the following SyntaxError when used without a specifier: > import(); < Uncaught SyntaxError: Unexpected token ) From the error message, it seems this the result of the code snippet being seen as static `import` followed by parens, as opposed to `import()` with no specifier. This patch makes this error message more clear: > import(); < SyntaxError: import() requires a specifier BUG=v8:7020,v8:6513 Change-Id: I3519dfd0029f38d23da858a5499f1d226e794935 Reviewed-on: https://chromium-review.googlesource.com/747141Reviewed-by:Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#49058}
-
Jakob Kummerow authored
Implicit case-fallthrough strikes again. Bug: v8:6791 Change-Id: Iee6422a67797f8958527507bac538bcdac2ebddc Reviewed-on: https://chromium-review.googlesource.com/747075Reviewed-by:
-
Jakob Kummerow authored
Objects with both dictionary and non-dictionary maps can store their hash in the {properties} field when they have no other properties. Bug: chromium:778952 Change-Id: I8ac8c31eaac32116415e3c65cef8dee260dca2c9 Reviewed-on: https://chromium-review.googlesource.com/747272Reviewed-by:
-
