- 30 Aug, 2019 2 commits
-
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/370f887..d2d4319 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/4b46042..8fe3e6a Rolling v8/third_party/googletest/src: https://chromium.googlesource.com/external/github.com/google/googletest/+log/eb56ee5..565f1b8 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/2993c5f..3d3532b TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: Ia4c8198c1491b1ffbe9a57ecf350e949e3e1032f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1777322Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#63468}
-
Michael Achenbach authored
NOTRY=true TBR=tmrts@chromium.org Change-Id: I6ffee170454ca8362591f9f650b3a6ac8bb09552 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776091Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#63467}
-
- 29 Aug, 2019 31 commits
-
-
Ng Zhi An authored
This is only for turbofan and interpreter, and simd lowering for 64x2 is not implemented yet. Bug: v8:8460 Change-Id: I0d046cb39ff64936da772e0db9a86b88b1509ac2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1769194 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#63466}
-
Adam Klein authored
This reverts commit 1fba0441. Reason for revert: blocks V8 roll due to layout test failures caused by error message changes: https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/347 Original change's description: > [destructuring] Elide coercible check for simple keys > > Simple object destructuring, such as `let {a,b} = o`, is less efficient > than the equivalent assignments `let a = o.a; let b = o.b`. This is > because it does a nil check of `o` before the assignments. However, this > nil check is not strictly necessary for simple (i.e. non-computed) names, > as there will be an equivalent nil check on the first access to o in > `o.a`. For computed names the computation is unfortunately obervable. > > So, we can elide the nil check when the first property (if any) of the > destructuring target is a non-computed name. This messes a bit with our > error messages, so we re-use the CallPrinter to also find destructuring > assignment based errors, and fiddle with the error message there. As > a side-effect, we also get out the object name in the AST, so we can > output a slightly nicer error message. > > Change-Id: Iafa858e27ed771a146cd3ba57903cc73bb46951d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773254 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63453} TBR=leszeks@chromium.org,verwaest@chromium.org Change-Id: I74cf06ebd987e5b8bbe1831b0042c085edf37f5b No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776994Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#63465}
-
Z Nguyen-Huu authored
Bug: v8:8976 Change-Id: Id6449c0e2a473db7b1d3a1c143324d8810000374 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773558 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63464}
-
Michael Lippautz authored
Allow querying whether an object is capable of holding information that is relevant to the embedder in its embedder fields. Bug: chromium:999262 Change-Id: Iced1a1cc78142481990d40d91d8e70e6e5518c5b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773268Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#63463}
-
Milad Farazmand authored
Port 213504b9 Original Commit Message: The code fields in a JSRegExp object now either contain irregexp compiled code or a trampoline to the interpreter. This way the code can be executed without explicitly checking if the regexp shall be interpreted or executed natively. In case of interpreted regexp the generated bytecode is now stored in its own fields instead of the code fields for Latin1 and UC16 respectively. The signatures of the jitted irregexp match and the regexp interpreter have been equalized. R=pthier@google.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I2b0b82e76a800408ced2e92e811ce5e8dac2cf0f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1775725Reviewed-by:
Joran Siu <joransiu@ca.ibm.com> Reviewed-by:
Milad Farazmand <miladfar@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#63462}
-
Ulan Degenbaev authored
This reverts commit 8fdb2387. Original change's description: > "Reland x4 [arraybuffer] Rearchitect backing store ownership" > > This is a reland of bc33f5ae > > Contributed by titzer@chromium.org > > Original change's description: > > [arraybuffer] Rearchitect backing store ownership > > > > This CL completely rearchitects the ownership of array buffer backing stores, > > consolidating ownership into a {BackingStore} C++ object that is tracked > > throughout V8 using unique_ptr and shared_ptr where appropriate. > > > > Overall, lifetime management is simpler and more explicit. The numerous > > ways that array buffers were initialized have been streamlined to one > > Attach() method on JSArrayBuffer. The array buffer tracker in the > > GC implementation now manages std::shared_ptr<BackingStore> pointers, > > and the construction and destruction of the BackingStore object itself > > handles the underlying page or embedder-allocated memory. > > > > The embedder API remains unchanged for now. We use the > > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to > > keep the backing store alive properly, even in the case of aliases > > from live heap objects. Thus the embedder has a lower chance of making > > a mistake. Long-term, we should move the embedder to a model where they > > manage backing stores using shared_ptr to an opaque backing store object. > > TBR=yangguo@chromium.org > > BUG=v8:9380,v8:9221,chromium:986318 > > Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005 > Commit-Queue: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63041} TBR=yangguo@chromium.org,clemensh@chromium.org,mstarzinger@chromium.org Change-Id: Iba55c7ab71e5642b5cb6aeb699d6fc9cf9061486 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771795Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#63461}
-
Milad Farazmand authored
Port f72c844a Original Commit Message: Port f5ab7d38 Port 65f3861e Original Commit Message: In a new test suite: "wasm-api-tests", using a new binary "wasm_api_tests", powered by gtest/gmock (like unittests). Also fix a bunch of issues that these tests uncovered, mostly to ensure that the stack is walkable. R=miladfar@ca.ibm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I565fba1a2437eb49be0c5247740f3fcac7b071db Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1775723Reviewed-by:
-
Ulan Degenbaev authored
Before this CL the main thread fetched the background GC stats and added them to the main runtime-call-stats table. This resulted in background GC stats showing up in the main thread trace. This CL switches the background GC stats to use worker thread runtime- calls-stats table. This is now consistent with other background components of V8 suchs background compiler and parser. Bug: v8:9508 Change-Id: Ic4c0685ded6024f78d0f22f81419fd5677202f25 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776083Reviewed-by:
-
Seth Brenith authored
This patch is mostly mechanical. A few changes in implementation-visitor.cc might be worth mentioning: - Don't generate both field offset macros and class definitions for the same class. This was mostly just to keep me from forgetting to remove the DEFINE_FIELD_OFFSET_CONSTANTS part when converting classes, but also helpfully flagged that FixedArrayBase wasn't using the generated class that it requested. - Generate forward declarations for all tq-defined classes in internal-class-definitions-tq.h. This is helpful for making things compile when classes have fields of other class types. - When generating accessors for union types, use the nearest class type that contains the entire union rather than plain Object. This is important for compile-time type safety. It also required a few minor fixes elsewhere (isolate.cc, modules.cc, scope-info.cc, source-text-module.cc, and a correction of the field types in CallHandlerInfo to match how they're set in api.cc). Change-Id: I3b9280e30779ce57fb9f3629eecfec898e26d708 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774976Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
-
Patrick Thier authored
The code fields in a JSRegExp object now either contain irregexp compiled code or a trampoline to the interpreter. This way the code can be executed without explicitly checking if the regexp shall be interpreted or executed natively. In case of interpreted regexp the generated bytecode is now stored in its own fields instead of the code fields for Latin1 and UC16 respectively. The signatures of the jitted irregexp match and the regexp interpreter have been equalized. Bug: v8:9516 Change-Id: I30e3d86f4702a902d3387bccc1ee91dea501fe4e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762513 Commit-Queue: Patrick Thier <pthier@google.com> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
-
Maya Lekova authored
Since this produces a few false positives, also implemented a whitelist mechanism to not report them. Also, add a couple of tests and implemented automated testing against test-expectations file. Bug: v8:9321 Change-Id: I2915a29fe1891e8bbc51118bbd95ae072c8de023 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773243 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
-
Leszek Swirski authored
Sloppy eval extends the outer declaration scope's context. This is also true for sloppy eval inside of other sloppy evals -- the outer declaration scope's context is extended rather than the outer sloppy eval's declaration scope. However, we consider eval scopes to also be declaration scopes, for the purposes of strict eval and caching lookup variables. So, we need to make sure that we skip through sloppy eval scopes when marking a scope as calls_sloppy_eval. In fact, we implement this rather as never marking sloppy eval scopes as calls_sloppy_eval, under the assumption that the parent scope will already have been marked calls_sloppy_eval by the outer eval. As a drive-by, fix a TODO to move this logic from calls_sloppy_eval() to RecordEvalCall(), rename the variable to something more meaningful, and make Snapshotting to use a new calls_eval bit on Scope. Bug: chromium:996751 Change-Id: I27ccc7ef429a7ce60b3bb02bf64a3820ae4a2c36 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773247 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#63455}
-
Francis McCabe authored
This reverts commit a5d279da. Reason for revert: Causing failures in UBSAN Linux See https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/7672 Original change's description: > [wasm-c-api][test] Run Wasm C API tests on bots > > by including them in the "bot_default" and "default" test sets. > The build targets are already up to date, only the test runner > needs to be updated. > > Change-Id: I06a4a35a8d00c25ab56874d8eb365418841a02ac > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768370 > Commit-Queue: Tamer Tas <tmrts@chromium.org> > Reviewed-by: Tamer Tas <tmrts@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63436} TBR=jkummerow@chromium.org,tmrts@chromium.org Change-Id: I5b78e45eeae11ce460d2cdecba4e3cf8eacdb4f8 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1775927Reviewed-by:
Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#63454}
-
Leszek Swirski authored
Simple object destructuring, such as `let {a,b} = o`, is less efficient than the equivalent assignments `let a = o.a; let b = o.b`. This is because it does a nil check of `o` before the assignments. However, this nil check is not strictly necessary for simple (i.e. non-computed) names, as there will be an equivalent nil check on the first access to o in `o.a`. For computed names the computation is unfortunately obervable. So, we can elide the nil check when the first property (if any) of the destructuring target is a non-computed name. This messes a bit with our error messages, so we re-use the CallPrinter to also find destructuring assignment based errors, and fiddle with the error message there. As a side-effect, we also get out the object name in the AST, so we can output a slightly nicer error message. Change-Id: Iafa858e27ed771a146cd3ba57903cc73bb46951d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773254Reviewed-by:Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Milad Farazmand authored
Port 2e0bc516 Original Commit Message: Similar to CheckNotAtStart, one can now apply an offset to the CheckAtStart operation. Due to a recent change, all callsites of CheckNotAtStart now need to pass an offset, whereas previously the offset was just assumed to be zero. R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I255ed27bd0d5bccfb9851696ca25f2bb4a984981 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1775721Reviewed-by:
-
Jakob Gruber authored
The maximal unoptimized frame size is calculated during instruction selection and will be needed during code generation (it will be applied as an offset to the stack check). Pass the information along to the code generator through PipelineData. Bug: v8:9534 Change-Id: Ia72cd70d57c3de2db9fe43d91b9378d8e2ab8a0a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762302 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63451}
-
Joshua Litt authored
Adds a simple static class to manage fast path protectors, thereby eventually allowing us to remove a bunch of boilerplate from isolate. Bug: v8:9463 Change-Id: I99306e5c914c16045d0b891bdc3c62cfd98fddfc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774187Reviewed-by:
-
Tobias Tebbi authored
TLDR: Inline less, but more where it matters. ~10% decrease in Turbofan compile time including off-thread, while improving Octane scores by ~2%. How things used to work: There is a flag FLAG_min_inlining_frequency that limits inlining by the callsite being sufficiently frequently executed. This call frequency was measured relative to invocations of the parent (= the function we originally optimize). At the same time, the limit was very low (0.15), meaning we mostly relied on the total amount of inlined code (FLAG_max_inlined_bytecode_size_cumulative) to limit inlining. How things work now: Instead of measuring call frequency relative to parent invocations, we should have a measure that predicts how often the callsite in question will be executed in the future. An obvious attempt at that would be to measure how often the callsite was executed in absolute numbers in the past. But depending on how fast feedback stabilizes, it can take more or less time until we optimize a function. If we just take the absolute call frequency up to the point in time when we optimize, we would inline more for functions that stabilize slowly, which doesn't make sense. So instead, we measure absolute call count per KB of executed bytecodes of the parent function. Since inlining big functions is more expensive, this threshold is additionally scaled linearly with the bytecode-size of the inlinee. The resulting formula is: call_frequency > FLAG_min_inlining_frequency * (bytecode.length() - FLAG_max_inlined_bytecode_size_small) / (FLAG_max_inlined_bytecode_size - FLAG_max_inlined_bytecode_size_small) The new threshold is chosen in a way that it effectively limits inlining, which allows us to increase FLAG_max_inlined_bytecode_size_cumulative without increasing inlining in general. The reduction in compile time (x64 build) of ~10% was observed in Octane, ARES-6, web-tooling-benchmark, and the standalone TypeScript benchmark. The hope is that this will reduce CPU-time in real-world situations too. The Octane improvements come from inlining more in places where it matters. Bug: v8:6682 Change-Id: I99baa17dec85b71616a3ab3414d7e055beca39a0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768366 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#63449}
-
Darius Mercadier authored
A recent CL (1762292 and 1765533) changed the FreeList strategy, switching to one that uses 46 categories rather than the previous 6 we had. This caused a reduction of V8's heap size by about 1-2% on average. However, because FreeListCategory is 56 bytes, rather than 4 bytes as one might expect (2 bytes offset, 1 byte for the category type, and 1 byte padding), the overall memory improvement is actually lower than that. For instance, when 256M memory is allocated, 1000 pages * 46 freelists * 56 bytes = 2.5M overhead (ie, 1% overhead) Ideally, FreeListCategory should only by 4 bytes: 2 bytes for the offset of the top() on the page, 1 byte for the category type, and 1 byte padding. This CL reduces the size of FreeListCategory by 24 bytes by removing some fields. More work should be done to reduce the size even further: - Remove the available_ counter (this require maintaining byte count at the page level rather than in each FreeListCategory; and maintaining that counter is not trivial, but doable). - Use a 16 bits offset to store the top() rather than a pointer. - Get rid of prev_ and next_: this change is the most complicated. It requires storing the space's pages in order, such that when one page's freelist is empty, we move on to the next page in the space. - the type_ field might even be removable, since this information can be deduced from the FreeListCategory's position in the page's array or FreeListCategory. Bug: v8:9329 Change-Id: I8fd72cfa31ca12ba0dbf10be3948a72caee15b57 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773270 Commit-Queue: Darius Mercadier <dmercadier@google.com> Reviewed-by:Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
-
Milad Farazmand authored
Port e101dfb7 R=mstarzinger@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:7742 LOG=N Change-Id: I013d461bce61deae032aee08b2b1d9dac591d66a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774960Reviewed-by:
-
Primiano Tucci authored
Doing some refactoring to perfetto build files. Rolling to ensure that we are not breaking embedders in the process. Cq-Include-Trybots: luci.v8.try:v8_linux64_perfetto_dbg_ng Bug: v8:8339 Change-Id: I88ab30cc809779e36aa7e5c141e8180cd239edae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773274 Auto-Submit: Primiano Tucci <primiano@chromium.org> Commit-Queue: Tamer Tas <tmrts@chromium.org> Reviewed-by:
Tamer Tas <tmrts@chromium.org> Cr-Commit-Position: refs/heads/master@{#63446}
-
Igor Sheludko authored
... to let C++ compiler know that isolate root is 4Gb aligned and give it a chance to generate a better code. Bug: v8:9353 Change-Id: Ibd23c14cc44107c722a446a84dd14ca66f3bccfe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776079Reviewed-by:
-
Jakob Gruber authored
Similar to CheckNotAtStart, one can now apply an offset to the CheckAtStart operation. Due to a recent change, all callsites of CheckNotAtStart now need to pass an offset, whereas previously the offset was just assumed to be zero. Bug: chromium:996391 Change-Id: Ia59a584e93e5384479f05abddef7859b420b023a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773272 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Ross McIlroy authored
The helper would cause the stack to be unaligned during pushes which caused issues on Arm64. PushMultipleTimes is only used once by InterpreterEntryTrampoline, therefore it doesn't make sense to change it's behaviour for --optimize-for-size. Change-Id: I3bc7d39bc38ffd22a3ee6cca1cdafe5d656d77b5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773275 Auto-Submit: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Jakob Gruber authored
Printing regexp code used to behind the generic --print-code flag, but there was no way to distinguish between irregexp-generated code; and printing regexp bytecode was not supported at all (the --trace-regexp-bytecodes flag *did* exist, but prints the execution trace at runtime and not the generated bytecode sequence). This CL adds two new flags: --print-regexp-code --print-regexp-bytecode Regexp code is no longer printed as part of --print-code. Example output for --print-regexp-bytecode: generated bytecode for regexp pattern: .(?<!^.) 0x1ddcc614cbd0 0 PUSH_BT, 02, 00, 00, 00, c0, 00, 00, 00 ....... 0x1ddcc614cbd8 8 LOAD_CURRENT_CHAR, 11, 00, 00, 00, b0, 00, 00, 00 ....... 0x1ddcc614cbe0 10 CHECK_CHAR, 18, 0a, 00, 00, b0, 00, 00, 00 ....... 0x1ddcc614cbe8 18 CHECK_CHAR, 18, 0d, 00, 00, b0, 00, 00, 00 ....... 0x1ddcc614cbf0 20 PUSH_CP, 01, 00, 00, 00 ... Bug: chromium:996391 Change-Id: I731defbd7cf9ed29753a39bb1d7205dc136ca950 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773249 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Leszek Swirski authored
This reverts commit 0736599a. This reverts commit 7e1fbe8f. Reason for revert: Still some crashes, reverting to unblock dev. TBR=ishell@chromium.org,tebbi@chromium.org Bug: v8:9606 Bug: chromium:997485 Bug: chromium:997989 Change-Id: I9a0cb5440bf4fce06c9e6134dacf5c03d512f049 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Ana Peško authored
Fix tier-up issue where we would continue to execute bytecode instead of tiering-up on x64. The problem was that the smi value is stored in upper 32 bits which would get truncated, so we were checking the wrong value. Change-Id: I609b56ad58621c6ab7642d0ce453563ce09ae097 Bug: v8:9566 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773269 Commit-Queue: Ana Pesko <anapesko@google.com> Reviewed-by:
-
Michael Lippautz authored
Provide copy ctor and assignment operators as it turned out that they are useful for embedders in certain scenarios when dealing with TracedGlobal handles without finalization callbacks. Bug: v8:9660 Change-Id: I2b04f540baeef61a0bc8329ca06b999571cbfe66 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773250 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/3fe260c..370f887 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/c9fdf26..4b46042 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/217195c..ee8d9ce Rolling v8/third_party/googletest/src: https://chromium.googlesource.com/external/github.com/google/googletest/+log/6a3d632..eb56ee5 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/2ddb2b2..2993c5f TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I4222ca7e78e668890d719e545dc65ee55cd3d314 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774396Reviewed-by:
-
Jakob Gruber authored
This extends --trace-block-coverage to output not only all raw coverage slots, but also a detailed trace of all information that is generated by coverage collection (i.e. after filtering and transforming collected counts and ranges). Example output: Coverage for function='GetCoverage', SFI=0x3d23ea6dfb59, has_nonempty_source_range=1, function_is_relevant=1 {start: 278, end: 441, count: 1} {start: 357, end: 440, count: 0} Bug: v8:6000,v8:9212 Change-Id: Ide09eb40999541df97409d0682a505ee0070b3a6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771777 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: -
Jakob Kummerow authored
by including them in the "bot_default" and "default" test sets. The build targets are already up to date, only the test runner needs to be updated. Change-Id: I06a4a35a8d00c25ab56874d8eb365418841a02ac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768370 Commit-Queue: Tamer Tas <tmrts@chromium.org> Reviewed-by:
-
- 28 Aug, 2019 7 commits
-
-
Irina Yatsenko authored
Command descriptions: !handles: print stats for handles or list them; !jo_prev, !jo_next, !jo_in_ range: print managed objects near the given address; !jo_in_range: print managed objects in the given range; !jot: print the tree of referenced objects, starting from a given root; !dp: 'dp'-like command, augmented with data about the managed pointers. Change-Id: Ic72dd52ee8c68bc559f37ae04870d4e63ae0d554 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1772694 Commit-Queue: Irina Yatsenko <irinayat@microsoft.com> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#63435}
-
Jun Lim authored
This CL try to use a phi as a branch condition if the control flow from the branch is known from previous conditions. This change will open up more branch folding opportunities for later pass. Change-Id: I26316ab3a68c2d58d0df53691981288a996d4ba1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1674484 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
-
Z Nguyen-Huu authored
Bug: v8:8996 Change-Id: I9927d7eb3b32f1f1eb07fd803e44d81bc205f390 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1772041 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
-
Z Nguyen-Huu authored
Currently the backing store and elements kind might not aligned aka backing store can be dictionary where elements kind is frozen/sealed element kinds or the other way around. The reason is that Object.preventExtensions change elements kind to DICTIONARY while Object.seal/freeze change elements kind to SEALED/FROZEN element kind. Apply both these operations can lead to that problem as in chromium:992914 To solve this issue, we avoid Object.preventExtensions to change backing store to dictionary by introducing new nonextensible elements kind. These new nonextensible elements kind are handled similar to frozen, sealed element kinds. This change not only fixes the problem but also optimize the performance of nonextensible objects. Change-Id: Iffc7f14eb48223c11abf3c577f305d2d072eb65b Bug: chromium:992914, v8:6831 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1760976 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#63432}
-
Ng Zhi An authored
Bug: v8:8665 Bug: v8:9418 Change-Id: Ice4778deb363649ae6ee9f5b5957171587b28798 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1769481Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#63431}
-
Sigurd Schneider authored
This change allows the KeyAccumulator to throw a range error if there are too many properties to be enumerated. This CL introduces extensive checks during key enumeration in the run-time, and might introduce regressions. If so, feel free to revert. Bug: chromium:918301 Change-Id: I6166c0b15f1a05eac7116a979f12ba4833d1d1b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545902 Auto-Submit: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
-
Dan Elphick authored
Replace several NewStringFromStaticChars calls with the explicit root string access. Bug: v8:9396 Change-Id: I381e676fa81de24e892afe703b804b7c724a6083 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774719Reviewed-by:
-
