- 30 Oct, 2019 3 commits
-
-
Dominik Inführ authored
Start experiment with promoting all young live objects during mark-compact. This CL sets always_promote_young_mc to true by default. Change-Id: I306527ad2a361fc3e0edcf684c5ccec2b1d6e491 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879938Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#64630}
-
Jakob Gruber authored
The `capture_ix` refers to all captures while `capture_count` only refers to named captures. Clarified by renaming `capture_count` to `named_capture_count` and removing the incorrect part of the DCHECK. The `>= 1` part of the condition must still hold since named captures can only refer to explicit capture groups, which start at index 1. Tbr: petermarshall@chromium.org Bug: chromium:1018592 Change-Id: If8a26f6661ba0483d585f74270b3b4a3853e2ca8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886810Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64629}
-
Zhao Jiazhong authored
Port 1e4bb087 https://crrev.com/c/1826728 Change-Id: If977914ef55eb65228f92fecd1c9e9d0f625fa2b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886716Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#64628}
-
- 29 Oct, 2019 26 commits
-
-
Johannes Henkel authored
Change-Id: Ie73b21c284052a66ce18f0686030ee0a11f49d3c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1887631 Commit-Queue: Johannes Henkel <johannes@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Johannes Henkel <johannes@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#64627}
-
Johannes Henkel authored
Also we're not creating these any more via StringUtil in blink, so these two helpers can go. Change-Id: Ifdf700171ebc46cfbd6ce0af9a6f6ba73419a5a8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1887689 Auto-Submit: Johannes Henkel <johannes@chromium.org> Reviewed-by:
-
Andreas Haas authored
The new API with v8::BackingStore should be used instead as explained in https://docs.google.com/document/d/1sTc_jRL87Fu175Holm5SV0kajkseGl2r8ifGY76G35k This also relaxes the pre-condition for [Shared]ArrayBuffer::Detach to not require externalization first. Bug: v8:9380, v8:9908 Change-Id: Idd119fcd28be84a2fae74ae86f7381fd997766f5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859628 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#64625}
-
Milad Farazmand authored
Changes introduced in 30ec6a89 generates compilation error in gcc 8.1.0: 8.1.0/include/c++/bits/stl_iterator_base_funcs.h:183:2: error: no match for 'operator--' (operand type is 'v8::internal::HandlerTable::LookupReturn(int)::Iterator') --__i; Which maybe caused by the following change in stl_iterator_base_funcs: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=248875 Overloading the "--" operator fixes the compilation error. Change-Id: I32f54ddd4993375bf905996b5b1e66cd005256da Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1888190 Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Milad Farazmand authored
Port 3c6ecf71 Original Commit Message: Object::operator-> was removed in https://chromium-review.googlesource.com/c/v8/v8/+/1624788 but a few subclasses still had their own implementations. R=seth.brenith@microsoft.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I0f4902250ef1f80d2e06c71f27a0bee0717cf5ec Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1888191Reviewed-by:
Milad Farazmand <miladfar@ca.ibm.com> Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#64623}
-
Clemens Backes authored
This flag would help customers understand why Liftoff bails out, thus make it available also in release builds. R=jkummerow@chromium.org Change-Id: Ie2f69cbeaee617632f772030a3e03f052f688a10 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1888071Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64622}
-
Frank Tang authored
Bug: v8:9912 Change-Id: Ib9deba176f7aaa2ffca2db811c5273af673028ca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1884955Reviewed-by:
-
Ng Zhi An authored
There are a couple of bugs here: 1. The immediate used for vinsertps is wrong when lane == 1, the first two bits specify which element of the source is copied, and it should always be 00, 01 to copy the first 2 lanes of source. 2. For both cases, the second insertps call should be using dst as the src, since dst was already updated by the first insertps call, it was incorrectly using the old value of src. This was probably working correctly because in many cases dst and src happened to be the same register. 3. rep cannot be same as dst, because dst is overwritten, and rep should stay the same I also modified the F64x2ReplaceLane to test separately for replacing lane 0 and lane 1. Fixed bug 3. for arm and arm64. Bug: v8:9728 Change-Id: Iec6e48bcfbc7d27908dd86d5f113a8b5dedd499b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1877055Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#64620}
-
Seth Brenith authored
Object::operator-> was removed in https://chromium-review.googlesource.com/c/v8/v8/+/1624788 but a few subclasses still had their own implementations. Change-Id: Ie2c4df4cd0af0bdba8838aaf2f3852c61e227aa4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1884950Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#64619}
-
Johannes Henkel authored
New revision: d2fc9b958e1eeb1e956f3e2208afa9923bdc9b67 To roll this I need to update some call sites; this is because the Serializable interface is changing. Upstream change / review was here: https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/1879870 Change-Id: I93c4747609c6003baf1c160a68b8fb6bb07ac565 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879519Reviewed-by:
-
Sathya Gunasekaran authored
Bug: chromium:1016709 Change-Id: Ib239336cb6dde7c5d555d31911453bff138a23e1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886921Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64617}
-
Santiago Aboy Solanes authored
CallDebugOnFunctionCall was always using Registers and not Immediates. Then ParameterCount is not really needed. Since updating that, we could update other functions, e.g InvokeFunction, to only use registers too. Also removed now irrelevant variables, e.g definitely_mismatches. Bug: v8:9771 Change-Id: I83382c146dd47ccb8bb329f5becb5e941e4c3968 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1871605Reviewed-by:
Dan Elphick <delphick@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#64616}
-
Ross McIlroy authored
Inlines UpdateEffectControlWith and AddClonedNode in GraphAssembler to address a regression in some benchmarks caused by Add the ability for GraphAssembler to update basic blocks. BUG=chromium:1018661,v8:9684 Change-Id: I05513c13305465310552448192e0474f5aaa4a20 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886917 Auto-Submit: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
-
Clemens Backes authored
This adds some arguments to trace events to better see whether large times spent in these events are reasonable. R=mstarzinger@chromium.org Change-Id: I6097d988875d4911aff9741a1ed16590a442f60b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886912Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64614}
-
Liviu Rau authored
Fixed problem with to_string Bug: v8:9855 Change-Id: I5fdd9e77e78a77ab5a9aad833d8ac71bebd1a291 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886910Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Liviu Rau <liviurau@chromium.org> Cr-Commit-Position: refs/heads/master@{#64613}
-
Pierre Langlois authored
When inlined allocations are disabled, the space->limit() does not point to the end of the current page. Instead, it points to the current allocation pointer so is the same as space->top(). See how the limit is computed, if heap()->inline_allocation_disabled(), then the limit will be the same as the requested allocation area: ``` Address SpaceWithLinearArea::ComputeLimit(Address start, Address end, size_t min_size) { DCHECK_GE(end - start, min_size); if (heap()->inline_allocation_disabled()) { // Fit the requested area exactly. return start + min_size; } else if (SupportsInlineAllocation() && AllocationObserversActive()) { // ... } else { // The entire node can be used as the linear allocation area. return end; } } ``` If we want to simulate filling up a whole page in the new space, we can instead look at the ToSpace's page_high() which will be the end of the current page in which we're allocating. Bug: v8:9906 Change-Id: I81113d151bc083cd22d17ea1a4fbae7fef9dff6d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886914Reviewed-by: -
Michael Starzinger authored
R=clemensb@chromium.org Change-Id: I38c851f258b49de75f538a9b893ab24b7a4d0586 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1883894 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
-
Pierre Langlois authored
Change-Id: I69f7ca5e10575ae936d084b75f2b06a2aa1a7e0f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886913Reviewed-by:
-
Igor Sheludko authored
1) don't print off-heap TypedArray elements with --mock-arraybuffer-allocator 2) print integer HeapNumbers in safe integer range with max precision: as 9007199254740991.0 instead of 9.0072e+15 Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng Bug: v8:4153 Change-Id: Ie79fc08c44374981a840772fde4f414458d31c52 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1883565 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
Georg Neis authored
Remove serialized_ flags where there's only one thing to be serialized and its pointer can be used instead. Bug: v8:7790 Change-Id: I489bb3085cef574f81f417f950898d4348f8b9ab Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886911Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#64608}
-
Clemens Backes authored
The {IsWasmFrame} check in {ComputeLocationFromStackTrace} only returned true for compiled frames, but not for interpreted ones. Thus, for interpreted frames we would run into the code for JS frames, which assumes that a {JSFunction} is available. This CL fixes this issue by renaming {IsWasmFrame} to {IsWasmCompiledFrame}, and introducing a new {IsWasmFrame} method which returns true for both compiled and interpreted frames. R=mstarzinger@chromium.org Bug: chromium:1018227 Change-Id: If83b4129edaad775a212ccb741f3c62eabc2addb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1883892Reviewed-by: -
Michael Achenbach authored
The targets were removed in: https://crrev.com/c/1865420 Bug: v8:9911 Change-Id: I3fef2af6f8c1975a4b540965c72eaf7f69f4c78e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1883893 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Nico Weber <thakis@chromium.org> Cr-Commit-Position: refs/heads/master@{#64606}
-
Victor Gomes authored
ClusterFuzzer found that a context can be created by a call to the runtime when checking for context extensions on the bytecode graph builder. That happens in large contexts. Bug: chromium:1019069 Change-Id: I7ab66dceedd56476ab972d7998ef4ca6896dc868 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886691Reviewed-by:
-
Liviu Rau authored
NOTRY=true NOTREECHECKS=true NOPRESUBMIT=true Bug: v8:9898 Change-Id: I571830a54659c674cc37eb5137c3c2a3216d2666 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1883895 Commit-Queue: Liviu Rau <liviurau@chromium.org> Reviewed-by:
-
Nico Hartmann authored
In some places objects where allocated on the heap and stored in a std::unique_ptr later. This CL changes this so that a The std::unique_ptr<T>(new T(...)) construct is replaced with std: :unique_ptr takes ownership of new objects immediately. std: :make_unique<T>(...) where possible. Change-Id: Icdb4c9e7536d2b437df1a5bb6c3ad94c97e1e4cc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1871916 Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#64603}
-
Michael Achenbach authored
NOTRY=true Change-Id: Ibd4d324736c6989ccbb61d1bc14e0c2fb1c1cb55 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1877195 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
-
- 28 Oct, 2019 11 commits
-
-
Ng Zhi An authored
Follow up from https://crrev.com/c/1874378, declare these SSSE3 instructions using a separate macro that declares the right scope. Bug: v8:9561 Change-Id: Ia4370a4dff9e9d13b08c5e95a45670556d6ff1e2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1875657Reviewed-by:
-
Ng Zhi An authored
This test is racy between postMessage and memory.grow. Bug: chromium:1010272 Change-Id: I2856b5e1c57aabdf7d51665f2406559819099169 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1878914Reviewed-by:
Shu-yu Guo <syg@chromium.org> Reviewed-by:
-
Victor Gomes authored
We know statically if a context has an extension slot or not, but that was dynamically checked. The CL lifts the ScopeInfo chain to the compiler and does the check statically, it only generates the undefined check if the context has an extension slot. Bug: v8:9744 Change-Id: I169d05bb11b36501e97af00d30ae44bedcd6be83 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876051 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
-
Deepti Gandluri authored
This reverts commit a4c5136e. Reason for revert: CLs to Skip test on Android, predictable builds reviewed, and will land following this CL. Original change's description: > Revert "[wasm] Fix incorrect check for growing shared WebAssembly.memory" > > This reverts commit 2599d3cc. > > Reason for revert: Test fails with OOM on Arm64 - N5X (https://ci.chromium.org/p/v8/builders/ci/V8%20Android%20Arm64%20-%20N5X/6514) and is racy on predictable builds (https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20predictable/27044) > > Original change's description: > > [wasm] Fix incorrect check for growing shared WebAssembly.memory > > > > Bug: chromium:1010272 > > Change-Id: Ieff61089255ee088fad45f15a0f1a8f93eeec94b > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869077 > > Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> > > Reviewed-by: Andreas Haas <ahaas@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#64525} > > TBR=mstarzinger@chromium.org,gdeepti@chromium.org,ahaas@chromium.org > > Change-Id: I738a4021a80202c9b822815b922de31f95054fe6 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: chromium:1010272 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879513 > Reviewed-by: Shu-yu Guo <syg@chromium.org> > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64554} TBR=mstarzinger@chromium.org,gdeepti@chromium.org,ahaas@chromium.org,syg@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: chromium:1010272 Change-Id: Ifbe32854a3d67063e43e2b07a8e649a4850a77d5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1884411Reviewed-by:
-
Seth Brenith authored
This change begins making use of the fact that Torque now knows about the relationship between classes and instance types, to replace a few repetitive lists: - Instance type checkers (single and range), defined in src/objects/instance-type.h - Verification dispatch in src/diagnostics/objects-debug.cc - Printer dispatch in src/diagnostics/objects-printer.cc - Postmortem object type detection in tools/debug_helper/get-object-properties.cc Torque is updated to generate four macro lists for the instance types, representing all of the classes separated in two dimensions: classes that correspond to a single instance type versus those that have a range, and classes that are fully defined in Torque (with fields and methods inside '{}') versus those that are only declared. The latter distinction is useful because fully-defined classes are guaranteed to correspond to real C++ classes, whereas only-declared classes are not. A few other changes were required to make the lists above work: - Renamed IsFiller to IsFreeSpaceOrFiller to better reflect what it does and avoid conflicts with the new macro-generated IsFiller method. This is the part I'm most worried about: I think the new name is an improvement for clarity and consistency, but I could imagine someone typing IsFiller out of habit and introducing a bug. If we'd prefer to keep the name IsFiller, my other idea is to rename FreeSpace to VariableSizeFiller and Filler to FixedSizeFiller. - Made Tuple3 extend from Struct, not Tuple2, because IsTuple2 is expected to check for only TUPLE2_TYPE and not include TUPLE3_TYPE. - Normalized the dispatched behavior for BigIntBase and HeapNumber. - Added a few new object printers. Bug: v8:7793 Change-Id: I5462bb105f8a314baa59bd6ab6ab6215df6f313c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1860314 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: -
Ross McIlroy authored
Add support to verify the update schedule after ScheduledEffectControlLinearization and ScheduledMachineLowering phases. To do so, we need to recompute the immediate dominator tree of the scheduled blocks. BUG=v8:9684 Change-Id: I849fb7e3e699ca56c5115d90a53006d517cf3fe5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1881160 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
-
Sigurd Schneider authored
OrderedHashTableHandler::Delete was missed in the migration CL crrev.com/c/1106160 because it had no callers. This CL also migrates said function and adds usages in tests which force instantiation (and ensure we catch these errors without MSVC). Bug: v8:9905 Change-Id: Ieb1d1c89754f98e1d88d841d2933f46a6a4820d0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1883891Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#64595}
-
Ross McIlroy authored
Otherwise we might reuse a node that is scheduled later in the unchanged block. BUG=v8:9684 Change-Id: I655b538384d5ed8782d3d9bbb883037462003693 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1881155 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
-
Santiago Aboy Solanes authored
Since we only care about one bit in the lower 32 bits, we can always perform smi checking while looking at the lower bits. This improves pointer compression, since we wouldn't need to decompress, while not affecting the non-pointer compression case. Change-Id: Ic020fefcc92de0516148f34a3caacc60ff29556b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876050 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
-
Michael Achenbach authored
Change-Id: I6086363dbdc4fc1e5c138597338bd3b3d4436231 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1883562Reviewed-by:
-
Toon Verwaest authored
Otherwise the expression scope may be in a weird state and DCHECKs for valid arrow functions in ValidateAndCreateScope willl unnecessarily fire. Bug: chromium:1018611 Change-Id: I101b8902dce07c29aacba3e7a5e6f86d66505d5b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879906Reviewed-by:
-
