- 03 Nov, 2017 13 commits
-
-
Clemens Hammacher authored
Instead of having one method for 32 bit integers and one for 64 bit, plus a templatized version to choose from those two, just implement one version which handles unsigned integers of any size. Also, make them constexpr. The Count{Leading,Trailing}Zeros{32,64} methods are kept for now in order to keep the amount of code changes small. Also, sometimes it improves readability by stating exactly the size of the argument, especially for leading zeros (where zero-extending would add more leading zeros). CountLeadingZeros now uses a binary search inspired implementation as proposed in Hacker's Delight. It's more than 20% faster on x64 if the builtins are disabled. CountTrailingZeros falls back to CountPopulation instead of counting in a naive loop. This is ~50% faster. R=mstarzinger@chromium.org Change-Id: I1d8bf1d7295b930724163248150444bd17fbb34e Reviewed-on: https://chromium-review.googlesource.com/741231Reviewed-by:Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#49106}
-
Camillo Bruni authored
Drive-by-fix: increase coverage in object literals test. Change-Id: Iccfdf35b29229f63b3e8c1d961bee56ee03da688 Reviewed-on: https://chromium-review.googlesource.com/751661Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#49105}
-
Clemens Hammacher authored
If an error is thrown in a setTimeout callback, exit d8 with an error code. This will allow us to test asynchronous failures better, see linked bug. R=yangguo@chromium.org CC=mathias@chromium.org Bug: v8:6981 Change-Id: Ifad152e6039f12dc4ceaac0bdc4b87f709898087 Reviewed-on: https://chromium-review.googlesource.com/738372Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#49104}
-
Ross McIlroy authored
Adds support for compiling top-level code on a background thread behind a flag. When the flag is enabled, any background-parsing-task will perform compilation as well as parsing. BUG=v8:5203 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I88ab05c97cd6aea8d6be26e27d8da327f2c9c3a8 Reviewed-on: https://chromium-review.googlesource.com/741716 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#49103}
-
Sergiy Byelozyorov authored
R=machenbach@chromium.org Bug: chromium:777893 Change-Id: I2816934494309da458589b7d9b0c46fba9beaf38 Reviewed-on: https://chromium-review.googlesource.com/741221 Commit-Queue: Sergiy Byelozyorov <sergiyb@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#49102}
-
Benedikt Meurer authored
We don't use ICs for the Array.prototype and the Object.prototype because the runtime has to be able to intercept them properly (for the global protectors). So we better make sure that TurboFan doesn't outsmart the system by storing to elements of either prototype directly. Bug: chromium:781116 Change-Id: I0f521601ef02c1b21018abd1bf1028fd8a811e84 Reviewed-on: https://chromium-review.googlesource.com/753089 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#49101}
-
Franziska Hinkelmann authored
Bug: Change-Id: I5be4eabfc61f885f380fbec27dc537ed5d031493 Reviewed-on: https://chromium-review.googlesource.com/753084Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Franziska Hinkelmann <franzih@chromium.org> Cr-Commit-Position: refs/heads/master@{#49100}
-
Benedikt Meurer authored
This reverts commit 68212c80. Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20noi18n%20-%20debug/builds/17200 Original change's description: > RegExp: Add the ability to switch flags on and off within the regexp > > R=yangguo@chromium.org > > This is a reupload of https://chromium-review.googlesource.com/c/v8/v8/+/571746 > with a different user, since the other one was not allowed to commit to V8 any > more. > > Bug: > Change-Id: I6171afd44e514f6c934390faab6f9bee3953ac77 > Reviewed-on: https://chromium-review.googlesource.com/752522 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49098} TBR=erik.corry@gmail.com,yangguo@chromium.org,erikcorry@chromium.org,jgruber@chromium.org Change-Id: I651c5618f09f43104af50cb1319ab7b49011573e No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/752802Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#49099}
-
Erik authored
R=yangguo@chromium.org This is a reupload of https://chromium-review.googlesource.com/c/v8/v8/+/571746 with a different user, since the other one was not allowed to commit to V8 any more. Bug: Change-Id: I6171afd44e514f6c934390faab6f9bee3953ac77 Reviewed-on: https://chromium-review.googlesource.com/752522 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#49098}
-
Tobias Tebbi authored
Internalizing a key in the KeyedStoreICGeneric avoids an expensive SetProperty runtime call. This improves the prepack benchmark by ~5%. In the micro-benchmark copy-object.js attached to the bug, it surfaces as a ~2.5x improvement. The performance improvement currently relies on the stub cache, since we don't search for transitions from within the CSA. As this CL puts additional stress on the stub cache, performance regressions wouldn't be too surprising. Bug: v8:6936, v8:6997 Change-Id: Id1469499a3ae5450519ff40d3c5a0915c6de0d45 Reviewed-on: https://chromium-review.googlesource.com/749951Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
-
Franziska Hinkelmann authored
Bug: Change-Id: I341ab2833896afcb1f97a6d4c3af3afb12a26b8a Reviewed-on: https://chromium-review.googlesource.com/753083Reviewed-by:
-
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:
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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 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:
-
