- 19 Jan, 2021 2 commits
-
-
Sathya Gunasekaran authored
There's no need for these extra protector checks as the actual checks are now fast -- we don't have to compare against function objects in every context but instead just do a very quick instance type check. Bug: v8:11256 Change-Id: I40cdf40c8c85e39354bcbd32a7808cd083c8e45b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2598586 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#72151}
-
Sathya Gunasekaran authored
This will allow us optimize the protector cell checks in the fast path from checking against the function object in every context to just doing a range check against the instance type. This patch adds new instance types for constructor functions that require such protector cell checks. Bug: v8:11256 Change-Id: Iea722f9c6326dfa470149dd02e689a23942097f4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595442Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#72146}
-
- 16 Dec, 2020 2 commits
-
-
Sathya Gunasekaran authored
Instead of looking up the specific maps in every native context, just check against the instance type. Bug: v8:11256 Change-Id: Ib50d599c014c95b03ba3260014dfcbd9ec82982c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2593337Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#71802}
-
Sathya Gunasekaran authored
Previously, we were looking up the prototype of the receiver and checking that against %TypedArrayPrototype% before invalidating the protector cell. This is incorrect as it's possible to patch the prototype and then change the constructor property, bypassing this check. This CL adds a new instance type to prototype of all TypedArray constructors and checks the receiver against this instance type. TBR: tebbi@chromium.org Bug: v8:11274, v8:11256 Change-Id: I2ff6280e4cf820b06c5593fe4addd36f7ac656c4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2594776 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#71799}
-
- 20 Nov, 2020 1 commit
-
-
Leszek Swirski authored
Because of LocalHeap safepoints, our existing assert scopes don't necessarily maintain the same guarantees as desired. In particular, DisallowHeapAllocation no longer guarantees that objects don't move. This patch transitions DisallowHeapAllocation to DisallowGarbageCollection, to ensure that code using this scope is also protected against safepoints. Change-Id: I0411425884f6849982611205fb17bb072881c722 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2540547 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#71319}
-
- 16 Nov, 2020 1 commit
-
-
Georg Neis authored
Main changes: - Remove the kUninitialized and kInvalidated cell type aliases. They were confusing because their meaning depended on the current value in the cell. I think kUninitialized was obsolete anyways. - Remove a DCHECK from the compiler. The property that was asserted, while true, is irrelevant. - Remove the obsolete function GetConstantType. The only left use was in the object printer, but it's pointless there because we already print the value anyways. Change-Id: Ic718c8ba39aeb5bf18f588535dfb755a023cb144 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2536647Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#71198}
-
- 13 Nov, 2020 1 commit
-
-
Georg Neis authored
Bug: v8:7790 Change-Id: I4b6ef907c66bdc0a327d211db2f86ebb75f969a7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2536638Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#71183}
-
- 03 Nov, 2020 1 commit
-
-
Frank Emrich authored
This CL adds partial support for objects whose slow mode dictionaries are OrderedNameDictionaries. This is the case for all slow mode objects if V8_DICT_MODE_PROTOTYPES is enabled. Bug: v8:7569 Change-Id: I0b5a0d751e6551e78121569ddefd9e00c164cc5a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2489692Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Frank Emrich <emrich@google.com> Cr-Commit-Position: refs/heads/master@{#70952}
-
- 28 Oct, 2020 1 commit
-
-
Tobias Tebbi authored
This CL splits the class definitions per .tq file, to realize the following relationship: A class defined in src/objects/foo.tq has a C++ definition in src/objects/foo.h. Torque then generates: - torque-generated/src/objects/foo-tq.inc An include file (no proper header) to be included in src/objects/foo.h containing the Torque-generated C++ class definition. - torque-generated/src/objects/foo-tq-inl.inc An include file (no proper header) to be included in src/objects/foo-inl.h containing inline function definitions. - torque-generated/src/objects/foo-tq.cc A source file including src/objects/foo-inl.h that contains non-inline function definitions. Advantages of this approach: - Avoid big monolithic headers and preserve the work that went into splitting objects.h - Moving a definition to Torque keeps everything in the same place from a C++ viewpoint, including a fully Torque-generated C++ class definition. - The Torque-generated include files do not need to be independent headers, necessary includes or forward declarations can just be added to the headers that include them. Drive-by changes: A bunch of definitions and files had to be moved or created to realize a consistent 1:1 relationship between .tq files and C++ headers. Bug: v8:7793 TBR: hpayer@chromium.org Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70853}
-
- 05 Oct, 2020 1 commit
-
-
Santiago Aboy Solanes authored
We can use tag dispatching to distinguish between the synchronized and non-synchronized accessors. Also eliminated the need of adding explicit "synchronized" in the name when using the macros. As a note, we currently have one case of using both relaxed and synchronized accessors (Map::instance_descriptors). Cleaned up: * BytecodeArray::source_position_table * Code::code_data_container * Code::source_position_table * FunctionTemplateInfo::call_code * Map::instance_descriptors * Map::layout_descriptor * SharedFunctionInfo::function_data Bug: v8:7790 Change-Id: I5a502f4b2df6addb6c45056e77061271012c7d90 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424130 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#70306}
-
- 25 Sep, 2020 1 commit
-
-
Tobias Tebbi authored
This is a reland of 64caf2b0 Original change's description: > [torque] refactor: use -tq only in filenames derived from .tq files > > This is to establish a naming rule for Torque-generated files: > - If the file is called foo/bar-tq..., then it is derived from a > file foo/bar.tq > - Otherwise it doesn't belong to a specific .tq file. > > So far, we attached -tq to all Torque-generated file names, where it > sometimes corresponded to a .tq file name and sometimes not. > It is not necessary to add -tq to file names to indicate that they are > Torque-generated, since they are already in a directory called > torque-generated, and we always refer to them as > "torque-generated/filename", so there is no confusion even though some > files now have the same name as a corresponding hand-written file, for > example factory.cc. > > TBR: hpayer@chromium.org > Bug: v8:7793 > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70060} Bug: v8:7793 TBR: hpayer@chromium.org jgruber@chromium.org Change-Id: I6c492bc64aee1ff167e7ef401825eca9097a7f38 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431565 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70137}
-
- 24 Sep, 2020 2 commits
-
-
Marja Hölttä authored
The actual fix is in LoadIC::ComputeHandler (checking lookup_start_object == holder instead of receiver == holder) + the LookupIterator changes for preserving lookup_start_object. The rest is renaming / refactoring. Reland: not relying on the prototype validity cell after all Previous version: https://chromium-review.googlesource.com/c/v8/v8/+/2414039 Bug: v8:9237, chromium:1127653 Change-Id: I1949442f8ddcecb776f0c5d2cf737cb75f80e313 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2428588Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#70112}
-
Marja Hölttä authored
This reverts commit ab7e6df0. Reason for revert: Several fuzz bugs: chromium:1131469, chromium:1131525, chromium:1131779 Original change's description: > [super ic] Fix more receiver vs lookup start object vs holder confusion > > The actual fix is in LoadIC::ComputeHandler (checking > lookup_start_object == holder instead of receiver == holder) + the > LookupIterator changes for preserving lookup_start_object. > > The rest is renaming / refactoring. > > Bug: v8:9237, chromium:1127653 > Change-Id: Ieef46fb46ababa79623951c48639429c5b552d2d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414039 > Commit-Queue: Marja Hölttä <marja@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70045} TBR=marja@chromium.org,ishell@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:9237 Bug: chromium:1127653, chromium:1131469, chromium:1131525, chromium:1131779 Change-Id: I1bad5ba1dcfe9a0de8ce775feac2d3bfd7264c8c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2426620 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#70107}
-
- 22 Sep, 2020 3 commits
-
-
Francis McCabe authored
This reverts commit 64caf2b0. Reason for revert: Seems to be causing a failure: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/38809? Original change's description: > [torque] refactor: use -tq only in filenames derived from .tq files > > This is to establish a naming rule for Torque-generated files: > - If the file is called foo/bar-tq..., then it is derived from a > file foo/bar.tq > - Otherwise it doesn't belong to a specific .tq file. > > So far, we attached -tq to all Torque-generated file names, where it > sometimes corresponded to a .tq file name and sometimes not. > It is not necessary to add -tq to file names to indicate that they are > Torque-generated, since they are already in a directory called > torque-generated, and we always refer to them as > "torque-generated/filename", so there is no confusion even though some > files now have the same name as a corresponding hand-written file, for > example factory.cc. > > TBR: hpayer@chromium.org > Bug: v8:7793 > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70060} TBR=jgruber@chromium.org,tebbi@chromium.org Change-Id: I6960fe540861947536c6ddfc0f4887ea80899fae No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7793 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424486Reviewed-by: Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#70065}
-
Tobias Tebbi authored
This is to establish a naming rule for Torque-generated files: - If the file is called foo/bar-tq..., then it is derived from a file foo/bar.tq - Otherwise it doesn't belong to a specific .tq file. So far, we attached -tq to all Torque-generated file names, where it sometimes corresponded to a .tq file name and sometimes not. It is not necessary to add -tq to file names to indicate that they are Torque-generated, since they are already in a directory called torque-generated, and we always refer to them as "torque-generated/filename", so there is no confusion even though some files now have the same name as a corresponding hand-written file, for example factory.cc. TBR: hpayer@chromium.org Bug: v8:7793 Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70060}
-
Marja Hölttä authored
The actual fix is in LoadIC::ComputeHandler (checking lookup_start_object == holder instead of receiver == holder) + the LookupIterator changes for preserving lookup_start_object. The rest is renaming / refactoring. Bug: v8:9237, chromium:1127653 Change-Id: Ieef46fb46ababa79623951c48639429c5b552d2d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414039 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#70045}
-
- 15 Jul, 2020 1 commit
-
-
Igor Sheludko authored
This is a follow-up fix for https://chromium-review.googlesource.com/c/v8/v8/+/2292230 In this CL fixes the case when the property cell is added to the dictionary but the value is not actually stored which leaves PropertyCell with the hole in the dictionary. Now the logic for GlobalDictionary matches the logic for NameDictionary - the property cell is added to the dictionary in LookupIterator::ApplyTransitionToDataProperty(). Bug: chromium:1104711, chromium:1105383 Change-Id: I56da16d85d13288fbc41fd60dbce556fec5e7d18 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2297472Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#68860}
-
- 10 Jul, 2020 1 commit
-
-
Leszek Swirski authored
Rather than marking deleted GlobalDictionary entries with a "The Hole" valued PropertyCell, we now remove those PropertyCells entirely and use the standard HashTable deleted item marker (also the Hole). This comes with several simplifications: 1) We no longer need a customizable IsKey method on HastTable shapes, which was only used by GlobalDictionary to mark "The Hole" cells as not real keys, 2) We can get rid of IsLive/IsKey from the Shape entirely, and define it directly in the HashTable, which will also allow us (in the future) to encourage caching of "undefined" and "Hole" where used for IsKey checks, 3) PropertyCell invalidation doesn't necessarily have to allocate a new replacement cell (specifically, on deletion), nor does it have to deal with cells that contain the Hole, 4) kNeedsHoleCheck is renamed to kMatchNeedsHoleCheck (to be explicit that this is only needed to guard IsMatch, which may do an indentity comparison and thus not need the HoleCheck guard). It's also moved out of BaseShape and into the various shapes that define IsMatch, to make them more explicitly think about the value, 5) Modified some while loops into for loops to allow clearer use of "continue" on successful hole checks. Change-Id: If591cbb6b49d59726bdc615413aba4f78fd64632 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2292230 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#68807}
-
- 25 May, 2020 1 commit
-
-
Daniel Clifford authored
Change-Id: I092c0d70bf517b4c714f5958b188d54030dd9774 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1932838 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#67954}
-
- 28 Apr, 2020 1 commit
-
-
Jakob Gruber authored
This reverts the changes made in https://chromium-review.googlesource.com/c/v8/v8/+/1695465 https://chromium-review.googlesource.com/c/v8/v8/+/1776078 We originally moved this protector to the native context to avoid cross-native-context pollution of protector state. Ideally, invalidating a protector in one NC should not affect any other NC. But as it turns out, having the protector on the NC causes more problems than it solves since all affected callers now need to find the correct native context to check. Sometimes (e.g. in CSA regexp builtins) it is possible to blindly check the current NC, but the reasoning behind this optimization is tricky to understand. Sometimes, fetching the correct NC is not possible due to access restrictions. These implementation complexities outweigh the (unknown) potential performance benefits. In the future we should attempt to move away from the protector concept for these kinds of checks. Bug: chromium:1069964,v8:9463 Change-Id: I2cbb2ec7266282165dae5e4a6c8bdbda520c50a9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157382Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67415}
-
- 21 Apr, 2020 1 commit
-
-
Jakob Gruber authored
This is a reland of 52412058 Original change's description: > [protectors] Add use counters to track invalidations > > ... to make real world protector invalidations measurable. > > Chromium CL: https://crrev.com/c/2149324 > > Drive-by: Add missing newline in protector tracing. > Drive-by: Consistent naming for the regexp species protector. > > Bug: v8:9496 > Change-Id: I3c7238aa8024e03ea9e89daf83345b8ec4f0d768 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2149428 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67149} Bug: v8:9496 Change-Id: I3c97bfa747e8429569eaa09ea909de73fc377efa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151363Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67261}
-
- 16 Apr, 2020 1 commit
-
-
Jakob Gruber authored
This reverts commit 52412058. Reason for revert: Use counters are not the right approach, we need histograms instead. Original change's description: > [protectors] Add use counters to track invalidations > > ... to make real world protector invalidations measurable. > > Chromium CL: https://crrev.com/c/2149324 > > Drive-by: Add missing newline in protector tracing. > Drive-by: Consistent naming for the regexp species protector. > > Bug: v8:9496 > Change-Id: I3c7238aa8024e03ea9e89daf83345b8ec4f0d768 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2149428 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67149} TBR=ulan@chromium.org,jgruber@chromium.org Change-Id: Ia36b598844fbad2166772298c2e2ec8f6b4f92b1 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9496 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151358Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67170}
-
- 15 Apr, 2020 1 commit
-
-
Jakob Gruber authored
... to make real world protector invalidations measurable. Chromium CL: https://crrev.com/c/2149324 Drive-by: Add missing newline in protector tracing. Drive-by: Consistent naming for the regexp species protector. Bug: v8:9496 Change-Id: I3c7238aa8024e03ea9e89daf83345b8ec4f0d768 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2149428Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67149}
-
- 03 Apr, 2020 1 commit
-
-
Bruce Dawson authored
This reverts commit 10360127. Reason for revert: This fix only had moderate impact and the underlying CPU bug has now been addressed. Original change's description: > Speculative fix to crashes from a CPU bug > > For the last few months Chrome has been seeing many "impossible" crashes > on Intel Gemini Lake, family 6 model 122 stepping 1 CPUs. These crashes > only happen with 64-bit Chrome and only happen in the prologue of two > functions. The crashes come and go across different Chrome versions. > Analysis of most of the crashes shows that the address of the crashing > instruction follows some patterns: > > When crashing in GetFieldIndex() the last byte of the address is always > 1c, 5c, 9c, or dc. > > When crashing in UpdateCaches (fewer unique samples) the last byte of > the address is always 5d or 9d. > > The address of the function is 0xc or 0xd bytes earlier so the crashing > functions always start with an address that ends in 10, 50, 90, or d0. > > Those addresses are for the crashes on a load of the __security_cookie. > The crashes also occasionally happen on the two instructions that follow > the __security_cookie load in which case the crashing instruction's > address has been seen to end with 23 or a3. This corresponds to a > function start address of 10 or 90. > > Since the crash involves reading incorrect instruction bytes when > crossing a 16-byte boundary and since the crash appears to only happen > with particular 16-byte alignments it seems reasonable to force the > function's alignments to a multiple of 32 to see if this reliably > avoids the crashes. This change uses the gcc/clang __attribute__ > directive to force 32-byte alignment. I have tested this change enough to > verify that it triggers the desired alignment (with up to 31 "int 3" > instructions added for padding) but since I have never reproduced this > crash I have no way of testing its efficacy. > > Bug: chromium:968683, chromium:964273 > Change-Id: Ia6e1c6d1e044b84d274817374b25523303e78b51 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803775 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Bruce Dawson <brucedawson@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63804} TBR=brucedawson@chromium.org,verwaest@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: chromium:968683, chromium:964273 Change-Id: I150ecfebeff95e8f63dbba74d78491867dc17736 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2134728 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Auto-Submit: Bruce Dawson <brucedawson@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#66977}
-
- 03 Mar, 2020 1 commit
-
-
Leszek Swirski authored
Remove Isolate parameters from some dictionary methods, and change others to use ReadOnlyRoots instead, to prepare for Isolate templatization in a future patch. One small side-effect is that the global dictionary's property cell's dependent code deoptimization has to dynamically get the Isolate when it needs to actually mark code for deoptimization, for method signature consistency. Given that this is the slow path anyway, it shouldn't matter. Bug: chromium:1011762 Change-Id: I707de9a74ca3b30423a1e5830a10729d6a404786 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2080369 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#66574}
-
- 10 Jan, 2020 2 commits
-
-
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: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#65694}
-
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: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#65690}
-
- 09 Jan, 2020 1 commit
-
-
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: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#65672}
-
- 19 Dec, 2019 1 commit
-
-
Igor Sheludko authored
... in object literals. Bug: chromium:1034973 Change-Id: Ie357eef4c46f87486f2c3756ba1c288ad25a93df Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1974070Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#65515}
-
- 26 Nov, 2019 1 commit
-
-
Jakob Kummerow authored
Bug: v8:4153 Change-Id: I036b3f464a635414e050972cee2dffbf3b44cafd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1918250 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#65164}
-
- 20 Nov, 2019 1 commit
-
-
Jakob Kummerow authored
They have to be in sync, so this patch updates both systems. Bug: v8:4153 Change-Id: I09252e41a710e79f823fe6818c1c6c0038faeb31 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903434Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#65078}
-
- 18 Oct, 2019 1 commit
-
-
Shu-yu Guo authored
DefineClass uses the ClassBoilerplate to directly construct the property descriptor array or dictionary for defining the class constructor and prototype, skipping use of the LookupIterator and the encapsulated protector update logic. This patch adds manual calls to UpdateProtector(), which is in particular relevant for the isConcatSpreadable protector. Bug: v8:9837 Change-Id: I7b9d8105d41f5f0f826ca2ce35d6bf3d1aeee6e7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863644 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#64368}
-
- 16 Oct, 2019 1 commit
-
-
Jakob Kummerow authored
for "entries", i.e. indices into the backing store (as opposed to "public indices" going into the hash function). This improves consistency and compiler-enforced type safety; no change in behavior is intended. Change-Id: I25e57e3ddcf18a406e2dfbd66786b6980c4e9615 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1852768 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#64317}
-
- 11 Oct, 2019 2 commits
-
-
Jakob Kummerow authored
This is for consistency and compiler-enforced type safety. No change in behavior intended. Change-Id: I31467832ba6c63fd5f97df9fee6221559b283d67 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1852766 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64244}
-
Jakob Kummerow authored
instead of plain uint32_t as entry. This provides some type safety, because the compiler will check that we are not mixing up indexes and entries. It also paves the way to consistently using size_t for TypedArray indexes. Bug: v8:4153 Change-Id: Ie0eb63693c871efda9860d3d288896819868b66a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1852765Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#64236}
-
- 23 Sep, 2019 1 commit
-
-
Joshua Litt authored
Bug: v8:9463 Change-Id: Ie0e04e102b56ffdfb636e94ef293bb0d46e5f4a9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1808485Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#63933}
-
- 17 Sep, 2019 1 commit
-
-
Joshua Litt authored
Bug: v8:9463 Change-Id: Ie36fc1b04b81dd091c4526123bee50d6b22d6917 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807044 Commit-Queue: Joshua Litt <joshualitt@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63839}
-
- 16 Sep, 2019 2 commits
-
-
Bruce Dawson authored
For the last few months Chrome has been seeing many "impossible" crashes on Intel Gemini Lake, family 6 model 122 stepping 1 CPUs. These crashes only happen with 64-bit Chrome and only happen in the prologue of two functions. The crashes come and go across different Chrome versions. Analysis of most of the crashes shows that the address of the crashing instruction follows some patterns: When crashing in GetFieldIndex() the last byte of the address is always 1c, 5c, 9c, or dc. When crashing in UpdateCaches (fewer unique samples) the last byte of the address is always 5d or 9d. The address of the function is 0xc or 0xd bytes earlier so the crashing functions always start with an address that ends in 10, 50, 90, or d0. Those addresses are for the crashes on a load of the __security_cookie. The crashes also occasionally happen on the two instructions that follow the __security_cookie load in which case the crashing instruction's address has been seen to end with 23 or a3. This corresponds to a function start address of 10 or 90. Since the crash involves reading incorrect instruction bytes when crossing a 16-byte boundary and since the crash appears to only happen with particular 16-byte alignments it seems reasonable to force the function's alignments to a multiple of 32 to see if this reliably avoids the crashes. This change uses the gcc/clang __attribute__ directive to force 32-byte alignment. I have tested this change enough to verify that it triggers the desired alignment (with up to 31 "int 3" instructions added for padding) but since I have never reproduced this crash I have no way of testing its efficacy. Bug: chromium:968683, chromium:964273 Change-Id: Ia6e1c6d1e044b84d274817374b25523303e78b51 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803775Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Cr-Commit-Position: refs/heads/master@{#63804}
-
Joshua Litt authored
Bug: v8:9463 Change-Id: Ife5ea730166e76bdbe8b18eac1eb5688b7aaf150 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800513 Commit-Queue: Joshua Litt <joshualitt@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63795}
-
- 10 Sep, 2019 1 commit
-
-
Joshua Litt authored
Bug: v8:9463 Change-Id: I49d74c5103f4ee2e09114a609cffe82c838655dc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792782Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#63646}
-