- 19 Oct, 2020 1 commit
-
-
Frank Emrich authored
This adds a getter for ordered property dictionaries of maps Bug: v8:7569 Change-Id: I7e8668ec707734b97f41f1a85c70b00b3b10c981 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465824 Commit-Queue: Frank Emrich <emrich@google.com> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#70617}
-
- 07 Oct, 2020 1 commit
-
-
Leszek Swirski authored
Introduce an IsolateRoot class, which encapsulates the root address needed for pointer decompression. This class is implicitly constructible from both Isolate* and LocalIsolate*, allowing us to avoid templating methods that can take both, or awkwardly creating a `const Isolate*` from a `LocalIsolate*` just for getters. Change-Id: I6d4b9492409fc7d5b375162e381192cb48c8ba01 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440605 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#70365}
-
- 29 Sep, 2020 1 commit
-
-
Samuel Groß authored
This change moves external pointers into a separate table and turns external pointers in heap objects into indices into that table. This CL implements one of two possible ownership models for the table entries. With this one, every heap object owns its table entries, and they are allocated when the owning object is allocated. As such, setting external pointer fields does not require allocation of table entries. On the other hand, table indices cannot be shared between multiple objects. This CL does not yet implement freeing of external pointer table entires. This will later happen by a table garbage collector. Bug: v8:10391 Change-Id: I4d37785295c25a7d1dcbc9871dd5887b9d788a4f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235700Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Samuel Groß <saelo@google.com> Cr-Commit-Position: refs/heads/master@{#70204}
-
- 23 Jul, 2020 1 commit
-
-
Jakob Gruber authored
A small step for a JSFunction, one giant leap for V8. Tbr: clemensb@chromium.org Bug: v8:8888 Change-Id: I968bb819763994ec611cde7e502adea30339a387 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315979 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#69018}
-
- 07 Jul, 2020 1 commit
-
-
Ulan Degenbaev authored
This moves marking write barrier related functions from Heap and IncrementalMarking into a separate class: MarkingBarrier. Additionally, a new WriteBarrier class is added at the heap API level that dispatches to MarkingBarrier. Future CLs will move slots recording in MarkingBarrier and apply the same refactoring to the generational barrier. An instance of MarkingBarrier will be added to each LocalHeap and enable it to emit a write barrier from a background thread. Bug: v8:10315 Change-Id: Icc147b48563d88c85d99ead99b1e201f523721d0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2280083Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#68703}
-
- 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}
-
- 11 May, 2020 1 commit
-
-
Igor Sheludko authored
... when the element is read-only in one of the prototypes: * the length should not be updated, * in strict mode the store operation should throw TypeError. Bug: chromium:1055138 Change-Id: I7fc08e22c83f8a9848053cfe20851dc1b82f0e3d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172090 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#67717}
-
- 18 Mar, 2020 1 commit
-
-
Tobias Tebbi authored
In the runtime, we always had a convention to use int-typed accessors for Smi fields. For Torque-generated classes, we kept them Smi-typed but then added int wrappers around that. This CL makes Torque generate int-typed accessors directly, removing the need for these wrappers. TBR=hpayer@chromium.org Bug: v8:7793 Change-Id: I348e1d96295c9676fafda32b7d49088848527f89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106210 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#66760}
-
- 16 Mar, 2020 1 commit
-
-
Mythri A authored
With the current flow, it is difficult to easily get the output of --trace-opt, --trace-deopt and --trace-osr from Android devices. These flags log to stdout and on Android it is difficult to get this output that preserves the formatting. This cl redirects them to a file when --redirect-code-traces is specified. Change-Id: I8ea1f083d0ee4577f9d70cfd2d7cb2823fd1a6c4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089931 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#66722}
-
- 20 Jan, 2020 1 commit
-
-
Mythri A authored
When bytecode is flushed we also want to flush the feedback vectors to save memory. There was a bug in this code and we flushed ClosureFeedbackCellArray too. Flushing ClosureFeedbackCellArrays causes the closures created by this function before and after the bytecode flush to have different feedback cells and hence different feedback vectors. This cl fixes it so we only flush feedback vectors on a bytecode flush. Also this cl pretenures ClosureFeedbackCellArrays. Only FeedbackCells and FeedbackVectors can contain ClosureFeedbackCellArrays which are pretenured, so it is better to pretenure ClosureFeedbackCellArrays as well. Bug: chromium:1031479 Change-Id: I7831441a95420b9e5711f4143461f1eb7fa1616a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1980582 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#65866}
-
- 09 Jan, 2020 2 commits
-
-
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}
-
Ulan Degenbaev authored
This changes the marking worklist draining for the main thread marker and the concurrent marker to use the following algorithm in per-context mode: 1) Pop an object from the marking worklist. 2) Try to infer the native context that owns the objects. This is done using a new NativeContextInferrer class. 3) If the inference is successful, then change the active marking worklist to the worklist of the inferred native context. 4) Otherwise, keep the current active marking worklist. 5) Visit the object. Newly discovered objects will be pushed onto the active marking worklist. 6) Account the object size for the native context corresponding to the active marking worklist. This is done using a new NativeContextStats class. The main property of the algorithm is that each object for which we couldn't infer the native context is either attributed to the native context retaining it or is not attributed to any native context. Bug: chromium:973627 Change-Id: Ide4ab992275d115279f971d89ace657f4c05e176 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1981491 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#65663}
-
- 27 Nov, 2019 1 commit
-
-
Leszek Swirski authored
To indicate that the Isolate* in getters might not be a "real" isolate, but rather a calculated one from GetIsolateForPtrCompr only used for calculating the isolate root, make that function return a const Isolate* and change field getters, Object::IsFoo predicates, and related functions to all take a const Isolate* instead of an Isolate* With this change, we can slightly more confidently use Objects that are in OffThreadSpace, without having to worry too much about having an Isolate* floating around that could accidentally be used. This is a slight abuse of const semantics, but it allows implicit conversion from Isolate* arguments to the const Isolate* parameter. Bug: v8:7703 Bug: chromium:1011762 Change-Id: I54d4a65d2299477195f4d754cabe64ce34fdaa4c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1939455 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#65199}
-
- 18 Nov, 2019 1 commit
-
-
Tobias Tebbi authored
For many subclasses of JSObject, we used kSize instead of kHeaderSize even though they can contain in-object properties. In fact, kSize was very much used as the header size, as can be seen in many examples in this CL. This change is a preparation for a for a cleanup of how Torque generates field offsets. TBR=hpayer@chromium.org Change-Id: I350e996057cd66c427381334080f8ac93de88597 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1917141 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#65013}
-
- 11 Oct, 2019 2 commits
-
-
Seth Brenith authored
Design doc: https://docs.google.com/document/d/1ZU6rCvF2YHBGMLujWqqaxlPsjFfjKDE9C3-EugfdlAE/edit Changes from the design doc: - Changed to use 'class' declarations rather than 'type' declarations for things that need instance types but whose layout is not known to Torque. These declarations end with a semicolon rather than having a full set of methods and fields surrounded by {}. If the class's name should not be treated as a class name in generated output (because it's actually a template, or doesn't exist at all), we use the standard 'generates' clause to declare the most appropriate C++ class. - Removed @instanceTypeName. - @highestInstanceType became @highestInstanceTypeWithinParentClassRange to indicate a semantic change: it no longer denotes the highest instance type globally, but only within the range of values for its immediate parent class. This lets us use it for Oddball, which is expected to be the highest primitive type. - Added new abstract classes JSCustomElementsObject and JSSpecialObject to help with some range checks. - Added @lowestInstanceTypeWithinParentClassRange so we can move the new classes JSCustomElementsObject and JSSpecialObject to the beginning of the JSObject range. This seems like the least-brittle way to establish ranges that also include JSProxy (and these ranges are verified with static assertions in instance-type.h). - Renamed @instanceTypeValue to @apiExposedInstanceTypeValue. - Renamed @instanceTypeFlags to @reserveBitsInInstanceType. This change introduces the new annotations and adds the ability for Torque to assign instance types that satisfy those annotations. Torque now emits two new macros: - TORQUE_ASSIGNED_INSTANCE_TYPES, which is used to define the InstanceType enumeration - TORQUE_ASSIGNED_INSTANCE_TYPE_LIST, which replaces the non-String parts of INSTANCE_TYPE_LIST The design document mentions a couple of other macro lists that could easily be replaced, but I'd like to defer those to a subsequent checkin because this one is already pretty large. Bug: v8:7793 Change-Id: Ie71d93a9d5b610e62be0ffa3bb36180c3357a6e8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1757094 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64258}
-
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}
-
- 07 Oct, 2019 1 commit
-
-
Seth Brenith authored
Just mechanical conversion to remove boilerplate code. When .tq and .h files didn't agree on what a field is named, I used the name from the .h file. In a couple of cases the generated accessor became slightly more specific (HeapObject instead of Object), and I had to update the code that uses those accessors accordingly. Change-Id: Ie3af1590e3889887b167c9d045b07860b01f7d15 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776479Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#64142}
-
- 10 Sep, 2019 1 commit
-
-
Rong Wang authored
This CL is necessary for disabling write-barriers that involoves referencing pages via address arithmetic, which is required from third-party heap implementation. Change-Id: I1d3f572d48015e5c8cf691b2dc71a32834621c2f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781008Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#63644}
-
- 29 Aug, 2019 1 commit
-
-
Seth Brenith authored
This patch is mostly mechanical. A few changes in implementation-visitor.cc might be worth mentioning: - Don't generate both field offset macros and class definitions for the same class. This was mostly just to keep me from forgetting to remove the DEFINE_FIELD_OFFSET_CONSTANTS part when converting classes, but also helpfully flagged that FixedArrayBase wasn't using the generated class that it requested. - Generate forward declarations for all tq-defined classes in internal-class-definitions-tq.h. This is helpful for making things compile when classes have fields of other class types. - When generating accessors for union types, use the nearest class type that contains the entire union rather than plain Object. This is important for compile-time type safety. It also required a few minor fixes elsewhere (isolate.cc, modules.cc, scope-info.cc, source-text-module.cc, and a correction of the field types in CallHandlerInfo to match how they're set in api.cc). Change-Id: I3b9280e30779ce57fb9f3629eecfec898e26d708 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774976Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#63458}
-
- 28 Aug, 2019 1 commit
-
-
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:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#63432}
-
- 20 Aug, 2019 1 commit
-
-
Leszek Swirski authored
Since the mutability of HeapNumbers is determined by their owning object's descriptor array, we can remove the MutableHeapNumber type entirely, at the cost of a few fewer DCHECKs and a couple of TODOs to use the descriptor array information. This is a necessary step towards a follow-up which allows in-place Double -> Tagged transitions Design doc: https://docs.google.com/document/d/1VeKIskAakxQFnUBNkhBmVswgR7Vk6T1kAyKRLhqerb4/ Bug: v8:9606 Change-Id: I13209f9c86f1f204088f6fd80089e17d956b4a50 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743972 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#63294}
-
- 15 Jul, 2019 1 commit
-
-
Seth Brenith authored
This change is mostly mechanical, but it's worth mentioning a few slightly interesting cases: - A couple of field definitions didn't match the signedness of their corresponding accessors. - The generated accessors for Smi data use Smi values directly, but usually we want C++ accessors to use ints instead. I added a macro that hides the generated Smi accessors and exposes int accessors, but we might consider generating int accessors directly. - The data held in some fields is described in comments next to the accessor definition for those fields. With automatically generated accessors, those comments need a new home. In this change I put them in the Torque object definition, but I'm open to other suggestions. - gen-postmortem-metadata couldn't find updated class definitions after they got split across multiple lines, so I changed its matching logic. (Ideally debug-support.cc should be a Torque compiler output rather than something that involves parsing C++ with regexes, but this makes it correctly report subclass relationships for now.) - The end offsets generated by Torque were off by one from the values that would be generated by DEFINE_FIELD_OFFSET_CONSTANTS. Change-Id: I3df4fcd27997b46c41ca879065b9d97f6c939f07 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1692192Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#62719}
-
- 09 Jul, 2019 1 commit
-
-
Igor Sheludko authored
Tbr: verwaest@chromium.org Bug: v8:9353 Change-Id: I8164e2235ca43e203410277b86e6f166010c11d6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687673Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#62597}
-
- 28 Jun, 2019 1 commit
-
-
Igor Sheludko authored
The latter is better because it takes field type into account when decompressing field value. Drive-by: use [DECL_]ACCESSOR macros for some fields. Bug: v8:9353 Change-Id: I3d7f07d11b1e379e3e6cf0310d836af6b48c1338 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1680539 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#62444}
-
- 26 Jun, 2019 2 commits
-
-
Igor Sheludko authored
Bug: v8:9353 Change-Id: I740b2987da1719af6c3d4a6471e7f047801cfd5b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1678368Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#62391}
-
Igor Sheludko authored
... for defining isolate-full getters. Bug: v8:9353 Change-Id: I91aa11bfe41ab61b2fa72c21018fc38753a846bd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1676286Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#62375}
-
- 24 Jun, 2019 1 commit
-
-
Mathias Bynens authored
We currently use the class name “JSValue” for JSObjects that wrap primitive values. This name is a common source of confusion. This patch switches to a name that’s more clear. In addition to manual tweaks, the patch applies the following mechanical global replacements: before | after --------------------------------|-------------------------------------- if_valueisnotvalue | if_valueisnotwrapper if_valueisvalue | if_valueiswrapper js_value | js_primitive_wrapper JS_VALUE_TYPE | JS_PRIMITIVE_WRAPPER_TYPE JSPrimitiveWrapperType | JSPrimitiveWrapper type jsvalue | js_primitive_wrapper JSValue | JSPrimitiveWrapper _GENERATED_JSVALUE_FIELDS | _GENERATED_JSPRIMITIVE_WRAPPER_FIELDS Change-Id: I9d9edea784eab6067b013e1f781e4db2070f807c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1672942Reviewed-by:
Tamer Tas <tmrts@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#62337}
-
- 17 Jun, 2019 2 commits
-
-
Seth Brenith authored
This change removes the special case in the Torque compiler for types that descend from JSObject: they will no longer get implicit "| Undefined" appended to their types for verification purposes. It removes any additional custom verification steps in objects-debug that are made redundant by that change. In order to do so safely, I categorized all cases where we were implicitly adding "| Undefined" to the field type, as follows: 1. Classes that aren't using the generated verifier function (we should probably revisit these, but for now we at least know they're safe): - JSGlobalObject - JSFinalizationGroup - JSFinalizationGroupCleanupIterator 2. Classes where the existing verifier is already at least as strict as what we would get after removing the implicit "| Undefined": - JSDate - JSPromise - JSRegExp - JSRegExpStringIterator - WasmMemoryObject - JSWeakRef - JSStringIterator - WasmExceptionObject - JSListFormat (fixed in part 1) - JSPluralRules (fixed in part 1) - JSRelativeTimeFormat (fixed in part 1) - JSSegmenter (fixed in part 1) - JSArrayBufferView (fixed in part 1) - JSTypedArray (fixed in part 1) 3. Classes where, to the best of my knowledge based on code inspection, we already initialize the object correctly to pass the new stricter generated verifier: - JSFunction - JSArrayIterator - JSMessageObject - JSBoundFunction - JSAsyncFromSyncIterator - WasmModuleObject - JSAsyncFunctionObject 4. Classes that needed some adjustment to their initialization order to avoid exposing uninitialized state to the GC: - JSArray (only in Factory::NewJSArray; Runtime_NewArray and CodeStubAssembler::AllocateJSArray already behave fine) - WasmTableObject - JSDateTimeFormat - JSNumberFormat - JSCollator - JSV8BreakIterator - JSLocale - JSSegmentIterator - JSModuleNamespace 5. Classes that had incorrect type definitions in Torque: - WasmGlobalObject (category 4 after correction) 6. Classes that weren't fully initialized due to bugs: - JSGeneratorObject - JSAsyncGeneratorObject Bug: v8:9311 Change-Id: I99ab303d3352423f50a3d0abb6eb0c9b463e7552 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1654980 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62228}
-
Igor Sheludko authored
Bug: v8:9353 Change-Id: Ie090f8f89eb4372845fe2c9d6aa74154c36f2d53 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662291 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#62221}
-
- 11 Jun, 2019 1 commit
-
-
Igor Sheludko authored
Tbr: ulan@chromium.org Bug: v8:9353 Change-Id: I99533e21fd186f6d0191f4f500d1a3055a0f92c1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648260 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#62082}
-
- 29 May, 2019 1 commit
-
-
Z Duong Nguyen-Huu authored
Bug: chromium:966460 Change-Id: I418eab656510fe3f799f552e75be10140d25bcab Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1625864Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Cr-Commit-Position: refs/heads/master@{#61922}
-
- 28 May, 2019 1 commit
-
-
Benedikt Meurer authored
This removes a special case from JSObject::WriteToField() where we didn't store anything in case of initializing a double field with the uninitialized sentinel. Instead we now store the hole NaN pattern there, as in other places. This makes it possible to do stricter checking in the TurboFan frontend when it comes to detecting bit patterns. Drive-by-fix: Refactor the related code in MigrateFastToFast() to make it easier to follow the control flow. Bug: v8:9299 Change-Id: Ic35d05c69fbbb136d422d29ce6abf2b09ebe22a6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631606Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#61879}
-
- 27 May, 2019 3 commits
-
-
Benedikt Meurer authored
This is a reland of 4b86fea5 with copy&paste typo in CodeStubAssembler::AllocateByteArray() fixed (bug led to holes in new space, which was crashing reproducibly on the ia32 bot). Original change's description: > [typedarray] Move external/data pointer to JSTypedArray. > > As the next step in supporting huge typed arrays in V8, this moves the > external/data pointer from the FixedTypedArrayBase backing store to the > JSTypedArray instance itself, and replaces the special backing stores > with a plain ByteArray (removing all the code for the FixedTypedArrayBase > class hierarchy). By doing so, we can drastically simplify the system > around typed arrays. > > Note: Several places in the code base used to check the instance type > of the elements backing store of a JSTypedArray instead of checking the > elements kind on the JSTypedArray map directly. Those had to be fixed, > since the backing store is now always a ByteArray. > > Drive-by-fix: Move all the typed elements access related code into the > elements.cc file to properly encapsulate the accesses. > > Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow > Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183 > Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646 > Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535 > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61855} Tbr: petermarshall@chromium.org Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183 Change-Id: I87fcdb28532c5f08cc227332a4d59546cb423810 Cq-Include-Trybots: luci.chromium.try:linux-rel, win7-rel Cq-Include-Trybots: luci.v8.try:v8_linux_shared_compile_rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631592Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#61864}
-
Clemens Hammacher authored
This reverts commit 4b86fea5. Reason for revert: Fails on linux shared: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20shared/31045 Original change's description: > [typedarray] Move external/data pointer to JSTypedArray. > > As the next step in supporting huge typed arrays in V8, this moves the > external/data pointer from the FixedTypedArrayBase backing store to the > JSTypedArray instance itself, and replaces the special backing stores > with a plain ByteArray (removing all the code for the FixedTypedArrayBase > class hierarchy). By doing so, we can drastically simplify the system > around typed arrays. > > Note: Several places in the code base used to check the instance type > of the elements backing store of a JSTypedArray instead of checking the > elements kind on the JSTypedArray map directly. Those had to be fixed, > since the backing store is now always a ByteArray. > > Drive-by-fix: Move all the typed elements access related code into the > elements.cc file to properly encapsulate the accesses. > > Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow > Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183 > Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646 > Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535 > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61855} TBR=ulan@chromium.org,yangguo@chromium.org,titzer@chromium.org,sigurds@chromium.org,petermarshall@chromium.org,bmeurer@chromium.org,szuend@chromium.org Change-Id: I0bc1f935de6063acf75a0f4bb8c0ba67428603fd No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183 Cq-Include-Trybots: luci.chromium.try:linux-rel, win7-rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631427Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#61856}
-
Benedikt Meurer authored
As the next step in supporting huge typed arrays in V8, this moves the external/data pointer from the FixedTypedArrayBase backing store to the JSTypedArray instance itself, and replaces the special backing stores with a plain ByteArray (removing all the code for the FixedTypedArrayBase class hierarchy). By doing so, we can drastically simplify the system around typed arrays. Note: Several places in the code base used to check the instance type of the elements backing store of a JSTypedArray instead of checking the elements kind on the JSTypedArray map directly. Those had to be fixed, since the backing store is now always a ByteArray. Drive-by-fix: Move all the typed elements access related code into the elements.cc file to properly encapsulate the accesses. Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183 Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646 Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#61855}
-
- 23 May, 2019 3 commits
-
-
Benedikt Meurer authored
There's a `Map::IsDictionaryMap()` method in addition to the `Map::is_dictionary_map()`, which apparently do very different things: The former checks whether the instance type of the Map is in a certain range (FIRST_DICTIONARY_TYPE to LAST_DICTIONARY_TYPE), while the latter checks the `is_dictionary_map` bit (which means that the backing store for the properties of a JSObject is in slow mode). To make matters worse there's also `CodeStubAssembler::IsDictionaryMap()`, which does the bit check similar to `Map::is_dictionary_map()`. And to make matters even worse the FIRST_DICTIONARY_TYPE to LAST_DICTIONARY_TYPE range also contains instance types for classes that aren't subclass of `Dictionary` (despite a comment stating the opposite). So in conclusion it's best to remove the confusing `Map::IsDictionaryMap()` method, which is anyways wrong, and just test explicitly for `NameDictionary`, `NumberDictionary` or `GlobalDictionary` in the appropriate places. Bug: v8:9183 Change-Id: If35f73261e3cc96938ebf499bf32be3ec725288b Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627330 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61770}
-
Yang Guo authored
TBR=bmeurer@chromium.org,leszeks@chromium.org Bug: v8:9247 Change-Id: I8d14d0192ea8c705f8274e8e61a162531826edb6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624220Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#61769}
-
Clemens Hammacher authored
This CL was generated by an automatic clang AST rewriter using this matcher expression: callExpr( callee( cxxMethodDecl( hasName("operator->"), ofClass(isSameOrDerivedFrom("v8::internal::Object")) ) ), argumentCountIs(1) ) The "->" at the expression location was then rewritten to ".". R=jkummerow@chromium.org TBR=mstarzinger@chromium.org,verwaest@chromium.org,yangguo@chromium.org Bug: v8:9183, v8:3770 No-Try: true No-Tree-Checks: true Change-Id: I0a7ecabdeafe51d0cf427f5280af0c7cab96869e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624209Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#61764}
-
- 21 May, 2019 2 commits
-
-
Toon Verwaest authored
Change-Id: Ifd8734aa682e238de54284c74209d236c7ac824f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1622110Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#61699}
-
Sigurd Schneider authored
Change-Id: I377e96fca2dff89a986b43f092ef7684d164cd9d Bug: v8:9264 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1617679 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#61695}
-