- 19 Feb, 2019 12 commits
-
-
Vadim Gorbachev (bmsdave) authored
There are now less that 400 days until the end of life of Python 2(aka _legacy_ Python) https://pythonclock.org/ . The code compatibility check for python2 and python3 used the following tools: futurize, flake8 You can see the reports here: https://travis-ci.com/bmsdave/v8/builds This CL was uploaded by git cl split. Bug: v8:8594 Change-Id: I2a90aaecb270f03aed1c0fc92da1a0e2621b0eb2 Reviewed-on: https://chromium-review.googlesource.com/c/1470101 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Sergiy Belozorov <sergiyb@chromium.org> Cr-Commit-Position: refs/heads/master@{#59678}
-
Vadim Gorbachev (bmsdave) authored
There are now less that 400 days until the end of life of Python 2(aka _legacy_ Python) https://pythonclock.org/ . The code compatibility check for python2 and python3 used the following tools: futurize, flake8 You can see the reports here: https://travis-ci.com/bmsdave/v8/builds This CL was uploaded by git cl split. Bug: v8:8594 Change-Id: Id7e2f3d5751d9f0428d28f92106748d71db0042e Reviewed-on: https://chromium-review.googlesource.com/c/1470122Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
-
Dan Elphick authored
This restores assertion scope marking in the bta command making it obvious which frames disallowed heap allocation for instance. Change-Id: Ie99ff06df95b6ab6820e53798b12b1cd1bd97338 Reviewed-on: https://chromium-review.googlesource.com/c/1477213Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#59676}
-
Vadim Gorbachev (bmsdave) authored
There are now less that 400 days until the end of life of Python 2(aka _legacy_ Python) https://pythonclock.org/ . The code compatibility check for python2 and python3 used the following tools: futurize, flake8 You can see the reports here: https://travis-ci.com/bmsdave/v8/builds This CL was uploaded by git cl split. Bug: v8:8594 Change-Id: I661c52a70527e8ddde841fee6d4dcba282b4a938 Reviewed-on: https://chromium-review.googlesource.com/c/1470123 Commit-Queue: Sergiy Belozorov <sergiyb@chromium.org> Reviewed-by:
-
Ulan Degenbaev authored
The test is sensitive to bytecode flushing. Bug: v8:8801 Change-Id: I2e290246681c014838be7411cc0ff68fd44c3590 Reviewed-on: https://chromium-review.googlesource.com/c/1477217Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#59674}
-
Tobias Tebbi authored
The access made unsafe were chosen according what's hot in JSTests/Regexp and Octane/regexp. Bug: chromium:932919 Change-Id: I8229370f2dd7d0937e9d561f6957fb9dba6d6a25 Reviewed-on: https://chromium-review.googlesource.com/c/1477270Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#59673}
-
Ulan Degenbaev authored
This reverts commit 932a5ca8. Reason for revert: breaks GC stress Original change's description: > [heap] Enable large objects in young generation > > Bug: chromium:852420 > Change-Id: Id1cde3450c5ca046029b17eee5dbe5132f299c3d > Reviewed-on: https://chromium-review.googlesource.com/c/1477212 > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#59669} TBR=ulan@chromium.org,hpayer@chromium.org,mlippautz@chromium.org Change-Id: I16f0705cf37fdc1708c605abd76d79dac3f1e825 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:852420 Reviewed-on: https://chromium-review.googlesource.com/c/1477278Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#59672}
-
Ulan Degenbaev authored
This reverts commit 49de5875. Reason for revert: breaks TSAN Original change's description: > [heap] Perform more embedder tracing in incremental marking step > > This should fix GC latency regressions introduced in 4c6598. > > Bug: chromium:926189, chromium:930844, chromium:930693,chromium:931629 > Change-Id: I81c91829badbeea82d6e44670d07794632869424 > Reviewed-on: https://chromium-review.googlesource.com/c/1477216 > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#59668} TBR=ulan@chromium.org,mlippautz@chromium.org Change-Id: Iac914fe695740558f0fac3ad0172f48114b57312 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:926189, chromium:930844, chromium:930693, chromium:931629 Reviewed-on: https://chromium-review.googlesource.com/c/1477277Reviewed-by:
-
Benedikt Meurer authored
When setting up the initial map for a (class or function) constructor, we always over-allocate a bunch of in-object properties, in case not all property assignments happen as `this.prop = val` assignments in the constructor. However this over-allocation was a bit too aggressive and added a slack of 8 to each class constructor (plus a minimum of two, when there was no `this.prop = val` assignment). So in total this would yield an object with initially 40 in-object property slots in case of a simple class hierarchy like this: ```js class A {}; class B extends A {}; class C extends B {}; class D extends C {}; new D; ``` While the slack tracking takes care of eventually shrinking the objects to appropriate sizes, this aggressive over-allocation is still going to hurt performance quite a bit in the beginning, and will also lead to more traffic on the minor GC for now good reason. Instead of the above, we now allocate a minimum of 2 in-object properties per class (in a hierarchy) and then add a slack of 8 in the end. Meaning for the example above we end up with 16 initial in-object property slots, which seems sensible. Bug: v8:8853 Change-Id: I4a11e35a8612ceef1d776ca2f0543a26c8c2a2bf Reviewed-on: https://chromium-review.googlesource.com/c/1477276Reviewed-by:Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#59670}
-
Ulan Degenbaev authored
Bug: chromium:852420 Change-Id: Id1cde3450c5ca046029b17eee5dbe5132f299c3d Reviewed-on: https://chromium-review.googlesource.com/c/1477212Reviewed-by:
-
Ulan Degenbaev authored
This should fix GC latency regressions introduced in 4c6598. Bug: chromium:926189, chromium:930844, chromium:930693,chromium:931629 Change-Id: I81c91829badbeea82d6e44670d07794632869424 Reviewed-on: https://chromium-review.googlesource.com/c/1477216Reviewed-by:
-
Jaroslav Sevcik authored
When installing getter/setter of non-extensible map with existing setter/getter of the same name, we introduce a new transition (so we have two transitions with the same name!). This triggers an assertion in map updater. This fix carefully checks that on the back-pointer path from non-extensible map to the extensible map there are only integrity level transitions. Otherwise, we just bail out. Bug: chromium:932953 Change-Id: I02e91c3b652428a84a9f5c58b6691ea9b1fc44d6 Reviewed-on: https://chromium-review.googlesource.com/c/1477067Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#59667}
-
- 18 Feb, 2019 23 commits
-
-
Victor Costan authored
Googletest is (at last) converging with industry-standard terminology [1]. We previously called test suites "test cases", which was rather confusing for folks coming from any other testing framework. Chrome now has a googletest version that supports _TEST_SUITE_ macros instead of _TEST_CASE_, so this CL cleans up some of the outdated usage. [1] https://github.com/google/googletest/blob/master/googletest/docs/primer.md#beware-of-the-nomenclature Bug: chromium:925652 Change-Id: I3cd02b9fa6dbece1594bbfd50a21ad7503c2aab9 Reviewed-on: https://chromium-review.googlesource.com/c/1475654Reviewed-by:
-
Maciej Goszczycki authored
FromTopOrLimit was both created and renamed to FromAllocationAreaAddress as part of https://codereview.chromium.org/1900423002/ Bug: v8:8562 Change-Id: I117cc566ed3a420c4419f0f0645c2e200be57def Reviewed-on: https://chromium-review.googlesource.com/c/1477214Reviewed-by:
Dan Elphick <delphick@chromium.org> Reviewed-by:
-
Tobias Tebbi authored
This addresses the JSTests/Array/OptFastForEach regression, which ends up spending a lot of time in the ToString builtin. Bug: chromium:932919 Change-Id: I53cfdc61841bf10a669e54c3fdc009ead295782b Reviewed-on: https://chromium-review.googlesource.com/c/1477068Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#59664}
-
Tobias Tebbi authored
This should recover the microbenchmark performance-regressions. Bug: chromium:932919 Change-Id: I00e2345428c8730035dc1164278006d687364de7 Reviewed-on: https://chromium-review.googlesource.com/c/1477063Reviewed-by:
-
Farazmand authored
Change-Id: Ic1f112ff47040024bc416a43867ddff08d51246c Reviewed-on: https://chromium-review.googlesource.com/c/1475333Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#59662}
-
tzik authored
Several parameter names of PromiseBuiltinsAssembler methods do not match to its definition, which confuses readers of the code. Change-Id: I8a43dd71b5a8d203cd040d754f8e650ecb203b82 Reviewed-on: https://chromium-review.googlesource.com/c/1476880Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Taiju Tsuiki <tzik@chromium.org> Cr-Commit-Position: refs/heads/master@{#59661}
-
Tamer Tas authored
Progress indicator calculates the percentage using the estimated amount of tests. When base tests produce more tests or when testrunner filters some tests, the percentage terminates over 100% or under it. This CL adds an informative message about how the percentage behaves. R=machenbach@chromium.org CC=yangguo@chromium.org,sergiyb@chromium.org Bug: v8:8728 Change-Id: I91cafd2579ea1894ac347ff7483c307cd46c545d Reviewed-on: https://chromium-review.googlesource.com/c/1477056Reviewed-by:
-
Maciej Goszczycki authored
Change-Id: I25a2299e5e261cc125c7ff0e1acdeddbd7f664ff Reviewed-on: https://chromium-review.googlesource.com/c/1475753Reviewed-by:
-
Ulan Degenbaev authored
Bug: chromium:933107 Change-Id: Ie3a485447f96228d5c8d7fc169c9aabf8ccf6599 Reviewed-on: https://chromium-review.googlesource.com/c/1477057Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#59658}
-
Mike Stanton authored
Reason for revert/reland: UBSan complained of unaligned reads. To improve the Torque debugging experience, we can add source positions for each line. This information is carried through the generated CSA code (in <output directory>/gen/torque-generated/*.cc) and embedded as SourcePositions in the Code object. At snapshot time, these SourcePositions are stripped from the Code object and turned into platform-appropriate line number debug information. At this time on Linux, you'll need to build with "is_clang=false" in order to use GCC, because crucial steps are missing in Clang's ability to convey the information into the binary successfully. This CL also introduces a flag to control the existing source information in CSA code. --enable-source-at-csa-bind is now set to false by default because it's a bit confusing to "hop" between source lines in .TQ files and in .CC files. I expect to continue making adjustments there, as I want to provide helpful debugging aids at the CSA level as well as the Torque level. The current configuration prioritizes Torque. TBR=tebbi@chromium.org Bug: v8:8418 Change-Id: Idb80467d3679ec2361386fe9b67597b93d7f72cf Reviewed-on: https://chromium-review.googlesource.com/c/1475763Reviewed-by:
-
Tobias Tebbi authored
To recover the performance regressions of FixedArray bounds-checks by default, disable bounds checks in the hot loops of ArrayIndexOf. Bug: chromium:932919 Change-Id: I977f063f6cb200a342e72a6361d56f945c442aec Reviewed-on: https://chromium-review.googlesource.com/c/1477059Reviewed-by:
-
Santiago Aboy Solanes authored
Also adding LoadTaggedPointerField and LoadAnyTaggedField that were missed on previous CLs. Similar to X64's CL: https://chromium-review.googlesource.com/c/v8/v8/+/1460953 Bug: v8:7703 Change-Id: I9c917aadace65d45204c3360aeeb7e9ece296e70 Reviewed-on: https://chromium-review.googlesource.com/c/1475474Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#59655}
-
Jakob Gruber authored
Correctness fuzzers need the global object to have a consistent shape across build configs. Bug: chromium:932877,chromium:932656,v8:7777 Change-Id: Id4e1251e50965b822bc4ef36c5ae2777864273d5 Reviewed-on: https://chromium-review.googlesource.com/c/1475768Reviewed-by:
-
Simon Zünd authored
This CL changes Array#sort to work roughly like: 1) Call [[Get]] on the receiver in [0, length) and store to FA 2) Use the existing TimSort to sort that FA 3) Call [[Set]] on the receiver in [0, length) using the result This has the advantage that we no longer need different fast-paths for the sorting algorithm itself, only for step 1 and 3. This results in a code size reduction of ~2650 bytes. This CL does not include optimizations that elides step 1 or 3. Change-Id: I7f2e35067a6ec356add8b0c50b160d76813c536d Reviewed-on: https://chromium-review.googlesource.com/c/1458237 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by: -
Mythri authored
These tests were timing out because we used to miss to runtime when storing keyed properties in lite mode. Now, the store ICs are updated to use fast path when possible even with lite mode. So, these should no longer timeout Bug: v8:8293 Change-Id: I63481768cc7d12c25c7f1a20ed1fa097979f2c50 Reviewed-on: https://chromium-review.googlesource.com/c/1475754Reviewed-by:
-
Simon Zünd authored
This CL changes "CaptureCurrentStackTrace" to use the FrameArrayBuilder. This way, simple and detailed stack traces use the same mechanism to capture stack traces. The stack trace API is implemented using the previously introduced StackTraceFrame class, which uses FrameArray as a backing store and can lazily initialize StackFrameInfo objects. R=jgruber@chromium.org, yangguo@chromium.org Bug: v8:8742 Change-Id: I716a9baa33d9ca1d2ef41a73fba26234a03b045b Reviewed-on: https://chromium-review.googlesource.com/c/1469822 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:
-
Maya Lekova authored
Bug: chromium:931664 R=neis@chromium.org Change-Id: I4ad8e79b9b64898034d72264e968fc0cd01909b9 Reviewed-on: https://chromium-review.googlesource.com/c/1477050 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#59650}
-
Daniel Clifford authored
In the process, cleanup the StoreFixedArray* operators and change most FixedArray element accesses so that they explicitly use the '.objects' and '.floats' fields. Bug: v8:7793 Change-Id: I3e45a9b7536ec76e1413b7e508d79a56b37604ff Reviewed-on: https://chromium-review.googlesource.com/c/1460948 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#59649}
-
Andrew Comminos authored
Signal a condition variable when profiling thread shutdown should occur, waking up a profiling thread that's currently waiting for the next tick. Mitigates the case where if a high sample interval is specified (e.g. 60s), the main thread is blocked until the next sample occurs due to a Sleep() call. Bug: v8:8843 Change-Id: Ied6b0bfb5c47a072ade17870911b961f5091f613 Reviewed-on: https://chromium-review.googlesource.com/c/1470953 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#59648}
-
Ulan Degenbaev authored
This replaces Heap::InNewSpace with Heap::InYoungGeneration and fixes tests that are sensitive to page size. Bug: chromium:852420 Change-Id: I32b1eafb45813ea3bdcbda075f9e6156aaf4c5e3 Reviewed-on: https://chromium-review.googlesource.com/c/1475766Reviewed-by:
-
Ulan Degenbaev authored
The page flags of a large object promoted during scavenge are not updated until the finalization of the scavenge. Thus during slots recording they still indicate that the large object is in the from space. The MarkCompactCollector::RecordSlot bails out for object in young generation, which results in missing old-to-old slot. The fix is to insert the slot directly to the remembered set. Bug: chromium:852420 Change-Id: Ib3d62e6d939191411729dbc2eb16b89a171a1e80 Reviewed-on: https://chromium-review.googlesource.com/c/1475765Reviewed-by:
-
Jakob Gruber authored
This reverts commit c9ef0405. Reason for revert: https://crbug.com/932034 Original change's description: > [builtins]: Optimize CreateTypedArray to use element size log 2 for calculations. > > TypedArrayElementsInfo now represents an element's size as a log 2 and typed as > uintptr. This simplifies and speeds up (avoids possible HeapNumber allocations) a > number of calculations: > > - Number of Elements (length) -> Byte Length - is now a WordShl > - Byte Length -> Number of Elements (length) - is now a WordShr > - Testing alignment (byte offset or length) - is now a WordAnd > > These element/byte length related calculations are encapsulated in > TypedArrayElementsInfo as struct methods. > > This reduces the size of CreateTypedArray by 2.125 KB (24%) on Mac x64.release: > - Before: 9,088 > - After: 6,896 > > This improves the performance of the following microbencmarks > - TypedArrays-ConstructWithBuffer: ~87% > - TypedArrays-SubarrayNoSpecies: ~28% > > Bug: v8:7161 > Change-Id: I2239fd0e0af9d3ad55cd52318088d3c7c913ae44 > Reviewed-on: https://chromium-review.googlesource.com/c/1456299 > Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Cr-Commit-Position: refs/heads/master@{#59531} TBR=peter.wm.wong@gmail.com,jgruber@chromium.org,petermarshall@chromium.org,szuend@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:7161, chromium:932034 Change-Id: I3da95447ce34f84d01629d2791868f3adcdfb387 Reviewed-on: https://chromium-review.googlesource.com/c/1475764 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Jon Kunkee authored
In the current version of the MSVC toolchain, it seems that the compiler finds a near-match for the FlushInstructionCache call in v8::internal::, so instead of looking in other namespaces for matching overrides it emits this error: C2660: 'v8::internal::FlushInstructionCache': function does not take 3 arguments This change works around this by explicitly stating the expected namespace. Bug: chromium:927113 Change-Id: Ie39d6fdd458646fc86a4a2b16a93d6888ef1a5ae Reviewed-on: https://chromium-review.googlesource.com/c/1462260Reviewed-by:
-
- 16 Feb, 2019 2 commits
-
-
Andrey Kosyakov authored
DevTools protocol is not supposed to carry structurally invalid utf8 as string payload. Bug: chromium:929862 Change-Id: I701eeb553e6bf22d887947dcd9f4b29af7a43e2b Reviewed-on: https://chromium-review.googlesource.com/c/1475665Reviewed-by:
Pavel Feldman <pfeldman@chromium.org> Reviewed-by:
-
Frank Tang authored
Bug: v8:7834 Change-Id: I54122c378ad79bca27b3f1258a18a1a04d444273 Reviewed-on: https://chromium-review.googlesource.com/c/1474551Reviewed-by:
Caitlin Potter <caitp@igalia.com> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#59642}
-
- 15 Feb, 2019 3 commits
-
-
Sigurd Schneider authored
This is a step towards making gn check pass on v8 without third_party Change-Id: I6a256d65159695e2ba2a5d44c0437cac9b28aa3a Bug: v8:8834, v8:8855 Reviewed-on: https://chromium-review.googlesource.com/c/1475460Reviewed-by:
-
Sigurd Schneider authored
Change-Id: I43efddcbd381be3d61deb94515842e582069ffb9 Bug: v8:8834 Reviewed-on: https://chromium-review.googlesource.com/c/1475465Reviewed-by:
-
Matt Gardner authored
This CL fixes a perf regression caused by: https://chromium-review.googlesource.com/c/v8/v8/+/1465182 A deopt loop was occurring for HOLEY_DOUBLE_ELEMENTS arrays when hole elements were used as anything other than a float64, such as a return value or storing into a non-double array. bug: chromium:932082 Change-Id: I27290e9669d80050027e76cb62b0f67b51788d0f Reviewed-on: https://chromium-review.googlesource.com/c/1474560Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
