- 29 Aug, 2019 21 commits
-
-
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:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#63456}
-
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 <jgruber@chromium.org> Reviewed-by:
Joran Siu <joransiu@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#63452}
-
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:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#63448}
-
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:
Peter Marshall <petermarshall@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:
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@{#63438}
-
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:Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#63437}
-
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 18 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:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#63434}
-
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:
Bill Budge <bbudge@chromium.org> Reviewed-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:
-
Georg Neis authored
in order to find out if that is the failing CHECK in a chrome crash report... Bug: chromium:996819 Change-Id: Ifdebbc88b0525e61a5b3f83caa0ce4279a8efb75 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774718 Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
-
Maya Lekova authored
Bug: v8:7790 Change-Id: I666f545f4b5b7b5aeaed4ce2910240ef54f40c0e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773251 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
-
Yang Guo authored
This partially reverts commit 763f63ff. Reason for the revert is that the breaking at stack overflow does not introduce improvement of usability, but rather exposes many issues caused by the fact that V8 cannot perform a lot of functionality close to the stack limit. We keep the test, slightly modified, and use a better way to detect stack overflow. Bug: chromium:997469 Change-Id: I32bdf96767812b19f138310cc2dbd6a818fbf031 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771792Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#63426}
-
Michael Starzinger authored
R=ahaas@chromium.org BUG=v8:7742 Change-Id: Ifaab43b3ca25eb3e03b7f02a2a3864ecc3f41d61 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771791Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#63425}
-
Jakob Gruber authored
This fixes an invalid assumption when emitting code for matching '^' (start of line) in multiline regexps and '\b', '\B' in general. What we used to do: if the current trace's cp_offset (the offset from the current position) was non-zero, we assumed that we were looking at subject string index 1 or greater (i.e.: not at the start of the string or before). This is no longer valid since cp_offsets can now be negative. This CL changes the logic to omit start- and bounds-checks only for strictly positive cp_offsets, where the above assumption still holds. Bug: chromium:996391 Change-Id: I79be4fc295c6f0b63e41c13d1e91fdd00f2f2b42 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771794 Commit-Queue: Erik Corry <erikcorry@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Erik Corry <erikcorry@chromium.org> Cr-Commit-Position: refs/heads/master@{#63424}
-
Dominik Inführ authored
Instead of fully reverting the CL that introduced the old-to-new invalidated set, simply do not filter recorded slots yet. Bug: v8:9454 Change-Id: I2b880f64f29e319056ad49e2284dca26eb8770f4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773252Reviewed-by:
-
Jakob Kummerow authored
The previous pseudo-smi storage scheme for caching call target addresses in a struct without requiring a custom visitor only works on uncompressed 64-bit platforms. This patch fixes other platforms (natural or compressed 32-bit) by boxing the address in a Foreign. Change-Id: I3c182c1d9ccae4858cac2757fc3daa40d1520998 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771780 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
-
Maya Lekova authored
Remove unnecessary call to Serialize. Change a Handle cast to a Ref cast. Add a CHECK to JSHeapBroker::SetFeedback that the source is valid. Bug: v8:7790 Change-Id: I6a2f10d45456c6b128beff009016009457dc109c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773248 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-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: I5c603680cf6dd295e9d11a4eba70785e6dc512ba Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773244 Auto-Submit: Primiano Tucci <primiano@chromium.org> Commit-Queue: Tamer Tas <tmrts@chromium.org> Reviewed-by:
-
Andreas Haas authored
At the moment we only run the js-api spec tests of the core API on our try bots. With the new staging process we want to introduce for WebAssembly language features, see https://docs.google.com/document/d/1hB8mpWmzmtaxZ8PuJEkAWLwFqXTjrw7mJ3Ge9W1dB4E, we also want to run the js-api spec tests of proposals for which we already staged the implementation. With this CL I do the following changes: 1) The tools/wasm/update-wasm-spec-tests.sh now copies the js-api spec tests of the main spec and of the proposals to test/wasm-js/tests, and then uploads this directory to google cloud storage. The main spec tests are in test/wasm-js/tests, the proposal tests are in test/wasm-js/tests/proposals/PROPOSAL_NAME/. 2) Adjust the test-runner in test/wasm-js to run tests in tests/* instead of data/test/js-api/*. Thereby it also runs the proposal tests in test/wasm-js/tests/proposals/PROPOSAL_NAME/. For the proposal tests, the test runner now also adds d8 flags. 3) Remove the dependency to https://github.com/WebAssembly/spec from DEPS. 4) Cleanup .gitignore and wasm-js.status 5) Disable spec tests we don't pass with the new proposal. R=tmrts@chromium.org Bug: v8:9653 Change-Id: Ib3420871f17cb146d6cc7868f5613942a7f79d84 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768372 Commit-Queue: Tamer Tas <tmrts@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/3f22131..3fe260c Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/7ad424d..c9fdf26 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/0e5fff1..217195c Rolling v8/third_party/googletest/src: https://chromium.googlesource.com/external/github.com/google/googletest/+log/ed2eef6..6a3d632 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I2994dedaf7a48656dd2a05860ef6c8f3efc6e69c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1772412Reviewed-by:
-
- 27 Aug, 2019 1 commit
-
-
Joshua Litt authored
Launching nullish behind a flag resulted in a small performance regression in the adwords parsing benchmark. From local tests, doing a little manual PGO seemed to improve performance slightly. Parse.duration on this benchmark dropped from 1,639.188 ms to 1,535.312 ms Bug: chromium:997652 Change-Id: I537985793cdf310a0dda5a69ded9f0ea2c0a7fb0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773098 Commit-Queue: Joshua Litt <joshualitt@chromium.org> Reviewed-by:
-
