- 10 Jan, 2020 30 commits
-
-
Santiago Aboy Solanes authored
Related ones are TryGetOwnProperty and CallGetterIfAccessor. Bug: v8:10021 Change-Id: I1b65c4260ab48b4431fa2b84a8be5789f24fa800 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993960 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#65704}
-
Clemens Backes authored
This is a follow-up to https://crrev.com/c/1993969. --perf-basic-prof is only supported on linux platforms, thus the {PerfBasicLogger} class does not need to be compiled on other platforms. R=ahaas@chromium.org Bug: chromium:1035233 Change-Id: Ic84fb6922f6c4ea5147ba7b54fbf43e557d6d792 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993978Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#65703}
-
Eric Leese authored
Change-Id: I7dd05e5b5feffceb1dd3b2a055c308266aea7c94 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1995272Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Milad Farazmand <miladfar@ca.ibm.com> Commit-Queue: Eric Leese <leese@chromium.org> Cr-Commit-Position: refs/heads/master@{#65702}
-
Seth Brenith authored
This change moves the definitions of the bitfield flags used by Symbol and Map to Torque. Symbol could directly follow the pattern established by SharedFunctionInfo, but Map required some other changes: - Until now, Torque bitfield definitions have required unsigned types. I thought that this would be the least-surprising behavior, since we never sign-extend when decoding bitfield values. However, I believe that the amount of churn involved in making ElementsKind be unsigned outweighs the benefit we were getting from this restriction (and similar difficulties are likely to arise in converting other bitfield structs to Torque), so this CL updates Torque to allow signed bitfield values. - If we try to make Map extend from all of the generated classes that define its flags, we end up with class sizing problems because some compilers only apply empty base class optimization to the first in a row of empty base classes. We could work around this issue by generating macros instead of classes, but I took this as an opportunity for a minor clean-up instead: rather than having bitfield definitions for several different bitfield structs all jumbled together in Map, they can be split up. I think this makes the code a little easier to follow, but if others disagree I'm happy to implement macro generation instead. Change-Id: Ibf339b0be97f72d740bf1daa8300b471912faeba Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1988934Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
-
Dominik Inführ authored
Change-Id: I826830e3eee1a597af183852ac8ab9f07706a8cf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1992429Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#65700}
-
Andreas Haas authored
R=jkummerow@chromium.org Bug: v8:10021 Change-Id: Ia90918507bb34d4a35e58d7b2895a6347b853fe3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993970Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#65699}
-
Thibaud Michaud authored
Non-embedded builtins are deprecated, and the "#ifdef" this comment is referring to was already removed. R=clemensb@chromium.org Bug: v8:10021 Change-Id: I043963d689e7c3c1bf7e9e44fd07c49f0f19cdd7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1995264Reviewed-by:
-
Zhao Jiazhong authored
Bug: v8:8974 Change-Id: Ib1e1c84b79190359d5ad519509b881e93d519604 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1989323 Commit-Queue: Clemens Backes <clemensb@chromium.org> Auto-Submit: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Reviewed-by:
-
Sigurd Schneider authored
This CL adds timestamps to coverage updates. This is useful for clients, because between requesting a coverage update and collecting coverage data significant time may pass. This change allows precise attribution at what time a coverage update was taken. Change-Id: I65a9cccb0171e892b7dbe35d105d3ca246ba08d0 Bug: chromium:1022031 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1992435Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#65696}
-
Clemens Backes authored
The fuzzers picked up this flag, and are now complaining that they run into UNREACHABLE/FATAL too often because the {PerfJitLogger} is not implemented on non-linux platforms. This CL removes the flag if it's not supported, so users get a warning about the unknown flag, but otherwise it's ignored. This should unblock the fuzzers, and slightly reduces binary size on non-linux. R=ahaas@chromium.org Bug: chromium:1035233 Change-Id: I6b9282318bc82ff23173bc83ae31cb2d8cbdcdb7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993969 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: -
Sigurd Schneider authored
This CL adds a mode to the JSReceiver::GetDataProperty that does not box unboxed double fields. This method can be used to fix a critical bug in the heap snapshot generator that currently causes a GC in a place where no GC should be caused. Change-Id: If195f6811090281d364e3c8fa221a1d6b96bcd80 Bug: v8:9993 Fixed: chromium:1038490 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993286 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#65694}
-
Maya Lekova authored
Bug: v8:10021 Change-Id: Ic9fecc8cdea8457652637bc3128addc145061be0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993965 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#65693}
-
Joshua Litt authored
This reverts commit e5e8685c. Bug: v8:9838 Change-Id: I3e45479a2470cb7891b39ac6f7d08404115aa7d5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1991954Reviewed-by:
-
Clemens Backes authored
During the property lookup, the strings will be internalized anyway. Doing it early will save the creation of duplicate strings by using the internalized object right away. This might fix the GC overhead we see for huge numbers of imports. R=ahaas@chromium.org Bug: chromium:1036737 Change-Id: I9c968a0652f394e977c6d061ef157037ebb0f7f9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993289 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Toon Verwaest authored
Otherwise we'll get weird semantics when enumerating objects after many deletes/reinserts. Bug: chromium:1033771 Change-Id: If0a459169c3794a30d9632d09e80da3cfcd4302c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993966 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#65690}
-
Mythri A authored
If feedback vector contains optimized code then we don't have to mark the closure for optimization. The optimized code would be installed on the next execution. Bug: chromium:1030415 Change-Id: Ifc6bbdf6f99ac835ace828fc812e89d1100622f9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993293Reviewed-by:
-
Santiago Aboy Solanes authored
There are some changes that stem from this, e.g Bind to =. Bug: v8:10021 Change-Id: Ia421578de7dce99ba843c2ec96b5e40bf3e2f941 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993297Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
-
Toon Verwaest authored
Also capture async stack traces if we're in a reject handler. Fixes node issue https://github.com/nodejs/node/issues/30822 Change-Id: I703012ddb88b5b5d17baba843a969b398ef99fa1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969897 Auto-Submit: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#65687}
-
Clemens Backes authored
This provides local scope information for Liftoff frames. Note that two things remain to be fixed: 1) We still need to refactor decoding of locals names such that it's available also for Liftoff frames. 2) We need to load spilled values from the stack frame. This will be added in a follow-up CL. R=jkummerow@chromium.org Bug: v8:10019 Change-Id: I2af1287d2989ab7b88c4293aac099bca95282063 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1991498 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Mythri A authored
Change-Id: Ia6576c0d99f240d222685f310981d23d76efc9b6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993974 Commit-Queue: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Auto-Submit: Mythri Alle <mythria@chromium.org> Reviewed-by:
-
Jakob Kummerow authored
When Heap::TearDown is called, parts of the Isolate are already gone (specifically: Managed<> objects, which includes Wasm NativeModules). Since heap verification can depend on these parts (e.g. to find Code objects belonging to current activations on the stack), we should do it before tearing down things. Heap::StartTearDown is a suitable way to achieve that. Bug: v8:9209 Change-Id: I44094b19e16a4f372eb14ab363d8b4a65182f38a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993968 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
-
Dan Elphick authored
Bug: v8:10021 Change-Id: I39ce7d592f0a517c6ff085cac98d354bc669147c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993294 Commit-Queue: Dan Elphick <delphick@chromium.org> Auto-Submit: Dan Elphick <delphick@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#65683}
-
Andreas Haas authored
The test passes, I guess it was fixed some time ago. R=thibaudm@chromium.org Bug: v8:10021 Change-Id: Id07344b2df24ae0ebff139f78eb4027d868b27c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993967Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#65682}
-
Jakob Kummerow authored
This patch maintains the previous default value of the flag controlling the max size of Wasm memories, but allows the limit to be raised on the command line. Bonus content: improve the multi-mapped mock allocator by falling back to regular allocation for small requests. More bonus content: make debug-mode Wasm tests faster. Bug: v8:6306 Change-Id: Idabae5734794b06e65d45b3a6165dbd488847f3f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1981157 Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
-
Jakob Kummerow authored
Addressing TODOs in the code to support size_t indices everywhere. Bug: v8:4153 Change-Id: I06432293799feed3b6a0c634cbbdcac250430d19 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962269Reviewed-by:
-
Clemens Backes authored
Change a {MaybeHandle} to {Handle}. We do utf8-validation during decode time (and verify this via DCHECK in {ExtractUtf8StringFromModuleBytes}), so the only case where it could happen that we return an empty handle there would be in an out-of-memory situation, and this is not handled correctly anyway, so it is better to just crash in that case (via {ToHandleChecked}). R=ahaas@chromium.org Bug: chromium:1036737 Change-Id: I6a0d94d920ab5dd7deecfa3e3033bdb5d266ffa7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993288Reviewed-by: -
Johannes Henkel authored
New Rev: 32a87e9a751db8f2903532134a7c8fc6932620ba Removes protocol::SerializedValue Upstream Review: https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/1991952 Change-Id: I4b3f216e748d60c371fac2fd22b94948dc29de72 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1991971Reviewed-by:
Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Johannes Henkel <johannes@chromium.org> Cr-Commit-Position: refs/heads/master@{#65678}
-
v8-ci-autoroll-builder authored
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/5217563..1f6ff4c Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/0d462e9..13928b7 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I96c47bc1db31e06ef28e42c3d3a4fb0c166e22fe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1994223Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#65677}
-
Yutaka Hirano authored
Discussed at https://github.com/whatwg/html/issues/5140. Bug: chromium:1030086 Change-Id: I9decbf300cf817a5cc3396a6cb7f276c8ed8ee25 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1990917Reviewed-by:
-
Ng Zhi An authored
Declare an inline method for the various backends to define based on alignment requirements. That way backends that might take a performance hit when data is not naturally aligned can specify the requirements. With this requirement defined, we can then specify that SIMD values require 16 bytes on the stack. This also opens up the possibility of storing 32-bit values in 32-bits, rather than the fixed kStackSlotSize. Bug: v8:9909 Change-Id: I9f35c08cc91fb493a81af296d72a603dcafaf644 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1974961Reviewed-by:
-
- 09 Jan, 2020 10 commits
-
-
Ng Zhi An authored
Bug: v8:9561 Change-Id: I18c832737cbea89e08af2ca166de7b01b7fe51b0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1986256Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#65674}
-
Zhao Jiazhong authored
port cb4ff11d https://crrev.com/c/1958051 Change-Id: I76a6af23264d4d8f08d5a8fb8cda7da206baeeea Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1990924 Auto-Submit: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Reviewed-by:
-
Jakob Kummerow authored
This CL factors out the decision-making logic whether a property key should be treated as a "property" or "element" into LookupIterator::Key, which can be constructed on its own, allowing use sites to take this distinction into account before constructing a LookupIterator from the Key, without needing to duplicate the logic. This also makes the assortment of LookupIterator constructors more uniform. Bug: chromium:1031175 Change-Id: I81d7b11ab7e4915f5c05668138e6e0c51ae11821 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962272 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
-
Maya Lekova authored
Bug: v8:7790 Change-Id: Idf066adcd5c3dca3004e2eaa0d8fa389755720af Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1991490Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#65671}
-
Clemens Backes authored
Store the types of locals in the {DebugSideTable}, and the type of all stack values on each entry. Especially the stack value types would be difficult to reconstruct later on. R=jkummerow@chromium.org Bug: v8:10019 Change-Id: I9b945b4e0a51166460420099908442703d3d486a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1975759 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: -
Andreas Haas authored
In the WebAssembly.Global constructor we continued to execute even after the JavaScript code in the descriptor.mutable getter threw an exception. This caused a problem when the descriptor.value getter was executed even though there was a scheduled exception. R=jkummerow@chromium.org Bug: chromium:1033948 Change-Id: Idac554175fe45ec677447b793db069eb6de543b7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993283Reviewed-by:
-
Seth Brenith authored
This change updates CachedTemplateObjectMap, BreakPointInfo, and BreakPoint to inherit directly from Struct rather than Tuple2 or Tuple3. It also removes Tuple3 because nothing else used Tuple3. By avoiding tuple types, we get various benefits that Torque can provide: - stricter debug verifier functions - accessors, cast functions, and printers are generated - BreakPoint and BreakPointInfo have different instance types, so you can tell them apart at runtime or in a debugger Change-Id: I9367bc08c6dea55d659fd610f9f6105fd61c907a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1988793Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#65668}
-
Johannes Henkel authored
Upstream PR: https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/1990896 New rev: dee0c0c65cc2df6284e75ae9fca083dc604c9fca Change-Id: I1a09d46ee572249bb2c3f4cbdfbc499b7e4f4aa9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1991803Reviewed-by:
-
Clemens Backes authored
This is a cleanup to remove unneeded flags after these changes (in https://crrev.com/c/1988548): * --future does not imply --wasm-tier-up any more, and * --wasm-tier-up does not imply --liftoff any more. Instead, now * --wasm-tier-up is enabled by default, * --wasm-tier-up has no effect if --liftoff is not set, and * --future implies --liftoff. R=ahaas@chromium.org Bug: chromium:1040061 Change-Id: I5d04ee1f1d84ddcd0654df0e0a4c6298f80aee9e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993280Reviewed-by:
-
Santiago Aboy Solanes authored
Fix for a bug introduced in https://chromium-review.googlesource.com/c/v8/v8/+/1977863 Change-Id: I4dbf259899005bb3b317bc5e8222d19c16abede4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993284Reviewed-by:
-
