1. 23 Jul, 2020 1 commit
  2. 10 Jul, 2020 1 commit
    • Leszek Swirski's avatar
      [hashtable] Allow GlobalDictionary to have holes · 82726b64
      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: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68807}
      82726b64
  3. 02 Jul, 2020 1 commit
  4. 10 Jun, 2020 1 commit
    • Georg Neis's avatar
      [runtime] Fix reentrancy bug in JSFunction::EnsureHasInitialMap · 0817d7ee
      Georg Neis authored
      Foozie came up with a mind-boggling example hitting a similarly
      mind-boggling bug: object construction (JSObject::New) wants to create
      the constructor's function initial map (JSFunction::GetDerivedMap ->
      JSFunction::EnsureHasInitialMap). To do so, it calls
      JSFunction::CalculateExpectedNofProperties. This harmless sounding
      function triggers compilation of the function. Since we're running with
      --always-opt, this is an optimizing compilation. Turbofan ends up
      depending on the function's "prototype" property, for which it wants to
      create the initial map so that it can install the code dependency. That
      is, EnsureHasInitialMap is reentered. At this point there is no further
      compilation attempt because the bytecode now exists. The initial map is
      created and installed on the function, and TF records the code
      dependency on that map. When CalculateExpectedNofProperties returns
      control to the outer EnsureHasInitialMap, yet another initial map is
      created and set on the function, forgetting the previous one and thus
      the code dependency.
      
      I'm not sure if this bug can only be observed with --always-opt. The fix
      is general.
      
      Bug: chromium:1092011
      Change-Id: I8b972748e49b9eb8f06fa17ea9ca037de2bd7532
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238570Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68292}
      0817d7ee
  5. 03 Jun, 2020 1 commit
  6. 15 May, 2020 1 commit
  7. 27 Apr, 2020 1 commit
    • Jakob Gruber's avatar
      Revert "Add counter to track `Date::getTimezoneOffset()`." · 054f5f69
      Jakob Gruber authored
      This reverts commit 14ebea15.
      
      Reason for revert: CountUsage() can't be called without a C entry frame.
      
      Note this counter was never hooked up in chromium. Besides removing the
      problematic CountUsage() call, this CL also makes the call path more
      robust against similar future issues by adding {gc,handle,js} disallow
      scopes.
      
      Original change's description:
      > Add counter to track `Date::getTimezoneOffset()`.
      >
      > Bug: chromium:915620
      > Change-Id: I75579080098632639b125b2252b3ab9615c7ea95
      > Reviewed-on: https://chromium-review.googlesource.com/c/1379876
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Commit-Queue: Mike West <mkwst@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#58306}
      
      TBR=yangguo@chromium.org,mkwst@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Tbr: ulan@chromium.org
      Bug: chromium:915620,v8:10460
      Change-Id: I2dd2e14947fe527de24ea644b4b33897f437a119
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2165790
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67399}
      054f5f69
  8. 24 Apr, 2020 2 commits
    • Timothy Gu's avatar
      Reland "[builtins] Clean up the use of class_name / ES5 [[Class]]" · 1aa51b49
      Timothy Gu authored
      This is a reland of 29c1eab9
      
      Original change's description:
      > [builtins] Clean up the use of class_name / ES5 [[Class]]
      >
      > Before ES2015, the ES spec had a [[Class]] internal slot for all
      > objects, which Object.prototype.toString() would use to figure the
      > returned string. Post-ES2015, the [[Class]] slot was removed in spec for
      > all objects, with the @@toStringTag well-known symbol the proper way to
      > change Object.prototype.toString() output.
      >
      > At the time, spec-identical handling without the use of [[Class]] was
      > implemented in V8 for all objects other than API objects, where issues
      > with the Web IDL spec [1] prevented Blink, and hence V8, to totally
      > migrate to @@toStringTag. However, since 2016 [2] Blink has been setting
      > @@toStringTag on API class prototypes to manage the
      > Object.prototype.toString() output, so the legacy [[Class]] handling in
      > V8 has not been necessary for the past couple of years.
      >
      > This CL removes the remaining legacy [[Class]] handling in
      > Object.prototype.toString(), JSReceiver::class_name(), and
      > GetConstructorName(). However, it does not remove the class_name field
      > in FunctionTemplateInfo, as it is still used for the `name` property of
      > created functions.
      >
      > This CL also cleans up other places in the codebase that still reference
      > [[Class]].
      >
      > This change should have minimal impact on web-compatibility. For the
      > change to be observable, a script must do one of the following:
      >
      > 1. delete APIConstructor.prototype[Symbol.toStringTag];
      > 2. Object.setPrototypeOf(apiObject, somethingElse);
      >
      > Before this CL, these changes will not change the apiObject.toString()
      > output. But after this CL, they will make apiObject.toString() show
      > "[object Object]" (in the first case) or the @@toStringTag of the other
      > prototype (in the latter case).
      >
      > However, both are deemed unlikely. @@toStringTag is not well-known
      > feature of JavaScript, nor does it get tampered much on API
      > constructors. In the second case, setting the prototype of an API object
      > would effectly render the object useless, as all its methods (including
      > property getters/setters) would no longer be accessible.
      >
      > Currently, @@toStringTag-based API object branding is not yet
      > implemented by other browsers. This V8 bug in particular has been an
      > impediment to standardizing toString behavior. Fixing this bug will
      > unblock [3] and lead to a better Web IDL spec, and better toString()
      > compatibility for all.
      >
      > [1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244
      > [2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4
      > [3]: https://github.com/heycam/webidl/pull/357
      >
      > Bug: chromium:793406
      > Cq-Include-Trybots: luci.chromium.try:linux-rel
      > Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996
      > Commit-Queue: Timothy Gu <timothygu@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67327}
      
      Bug: chromium:793406
      Change-Id: Ia5d97bd4e1c44cadc6f18a17ffc9d06b038cf8f1
      Cq-Include-Trybots: luci.chromium.try:linux-rel
      Cq-Include-Trybots: luci.v8.try:v8_linux_blink_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2163881
      Auto-Submit: Timothy Gu <timothygu@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67361}
      1aa51b49
    • Bill Budge's avatar
      Revert "[builtins] Clean up the use of class_name / ES5 [[Class]]" · 213016d6
      Bill Budge authored
      This reverts commit 29c1eab9.
      
      Reason for revert: Causes Blink test failures:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/4222
      
      Original change's description:
      > [builtins] Clean up the use of class_name / ES5 [[Class]]
      > 
      > Before ES2015, the ES spec had a [[Class]] internal slot for all
      > objects, which Object.prototype.toString() would use to figure the
      > returned string. Post-ES2015, the [[Class]] slot was removed in spec for
      > all objects, with the @@toStringTag well-known symbol the proper way to
      > change Object.prototype.toString() output.
      > 
      > At the time, spec-identical handling without the use of [[Class]] was
      > implemented in V8 for all objects other than API objects, where issues
      > with the Web IDL spec [1] prevented Blink, and hence V8, to totally
      > migrate to @@toStringTag. However, since 2016 [2] Blink has been setting
      > @@toStringTag on API class prototypes to manage the
      > Object.prototype.toString() output, so the legacy [[Class]] handling in
      > V8 has not been necessary for the past couple of years.
      > 
      > This CL removes the remaining legacy [[Class]] handling in
      > Object.prototype.toString(), JSReceiver::class_name(), and
      > GetConstructorName(). However, it does not remove the class_name field
      > in FunctionTemplateInfo, as it is still used for the `name` property of
      > created functions.
      > 
      > This CL also cleans up other places in the codebase that still reference
      > [[Class]].
      > 
      > This change should have minimal impact on web-compatibility. For the
      > change to be observable, a script must do one of the following:
      > 
      > 1. delete APIConstructor.prototype[Symbol.toStringTag];
      > 2. Object.setPrototypeOf(apiObject, somethingElse);
      > 
      > Before this CL, these changes will not change the apiObject.toString()
      > output. But after this CL, they will make apiObject.toString() show
      > "[object Object]" (in the first case) or the @@toStringTag of the other
      > prototype (in the latter case).
      > 
      > However, both are deemed unlikely. @@toStringTag is not well-known
      > feature of JavaScript, nor does it get tampered much on API
      > constructors. In the second case, setting the prototype of an API object
      > would effectly render the object useless, as all its methods (including
      > property getters/setters) would no longer be accessible.
      > 
      > Currently, @@toStringTag-based API object branding is not yet
      > implemented by other browsers. This V8 bug in particular has been an
      > impediment to standardizing toString behavior. Fixing this bug will
      > unblock [3] and lead to a better Web IDL spec, and better toString()
      > compatibility for all.
      > 
      > [1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244
      > [2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4
      > [3]: https://github.com/heycam/webidl/pull/357
      > 
      > Bug: chromium:793406
      > Cq-Include-Trybots: luci.chromium.try:linux-rel
      > Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996
      > Commit-Queue: Timothy Gu <timothygu@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67327}
      
      TBR=verwaest@chromium.org,timothygu@chromium.org
      
      Change-Id: I678d2ffc1064b1d1ddb62024cc23c6c41b216ef4
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:793406
      Cq-Include-Trybots: luci.chromium.try:linux-rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2163956Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Commit-Queue: Bill Budge <bbudge@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67349}
      213016d6
  9. 23 Apr, 2020 1 commit
    • Timothy Gu's avatar
      [builtins] Clean up the use of class_name / ES5 [[Class]] · 29c1eab9
      Timothy Gu authored
      Before ES2015, the ES spec had a [[Class]] internal slot for all
      objects, which Object.prototype.toString() would use to figure the
      returned string. Post-ES2015, the [[Class]] slot was removed in spec for
      all objects, with the @@toStringTag well-known symbol the proper way to
      change Object.prototype.toString() output.
      
      At the time, spec-identical handling without the use of [[Class]] was
      implemented in V8 for all objects other than API objects, where issues
      with the Web IDL spec [1] prevented Blink, and hence V8, to totally
      migrate to @@toStringTag. However, since 2016 [2] Blink has been setting
      @@toStringTag on API class prototypes to manage the
      Object.prototype.toString() output, so the legacy [[Class]] handling in
      V8 has not been necessary for the past couple of years.
      
      This CL removes the remaining legacy [[Class]] handling in
      Object.prototype.toString(), JSReceiver::class_name(), and
      GetConstructorName(). However, it does not remove the class_name field
      in FunctionTemplateInfo, as it is still used for the `name` property of
      created functions.
      
      This CL also cleans up other places in the codebase that still reference
      [[Class]].
      
      This change should have minimal impact on web-compatibility. For the
      change to be observable, a script must do one of the following:
      
      1. delete APIConstructor.prototype[Symbol.toStringTag];
      2. Object.setPrototypeOf(apiObject, somethingElse);
      
      Before this CL, these changes will not change the apiObject.toString()
      output. But after this CL, they will make apiObject.toString() show
      "[object Object]" (in the first case) or the @@toStringTag of the other
      prototype (in the latter case).
      
      However, both are deemed unlikely. @@toStringTag is not well-known
      feature of JavaScript, nor does it get tampered much on API
      constructors. In the second case, setting the prototype of an API object
      would effectly render the object useless, as all its methods (including
      property getters/setters) would no longer be accessible.
      
      Currently, @@toStringTag-based API object branding is not yet
      implemented by other browsers. This V8 bug in particular has been an
      impediment to standardizing toString behavior. Fixing this bug will
      unblock [3] and lead to a better Web IDL spec, and better toString()
      compatibility for all.
      
      [1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244
      [2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4
      [3]: https://github.com/heycam/webidl/pull/357
      
      Bug: chromium:793406
      Cq-Include-Trybots: luci.chromium.try:linux-rel
      Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996
      Commit-Queue: Timothy Gu <timothygu@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67327}
      29c1eab9
  10. 20 Mar, 2020 1 commit
  11. 18 Mar, 2020 1 commit
  12. 26 Feb, 2020 1 commit
  13. 20 Jan, 2020 1 commit
    • Mythri A's avatar
      Only flush feedback vector on bytecode flush · 92df7d10
      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: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65866}
      92df7d10
  14. 10 Jan, 2020 1 commit
  15. 09 Jan, 2020 1 commit
    • Ulan Degenbaev's avatar
      [heap] Implement per-context marking worklist draining · e27e6fd6
      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: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65663}
      e27e6fd6
  16. 13 Dec, 2019 1 commit
  17. 04 Dec, 2019 1 commit
    • Joyee Cheung's avatar
      [class] implement inspector support for private instance methods · 963ff849
      Joyee Cheung authored
      This patch implements inspector support for private instance methods:
      
      - Previously to implement brand checking for instances with private
        instance methods we store the brand both as the value with the brand
        itself as the key in the stances. Now we make the value the context
        associated with the class instead.
      - To retrieve the private instance methods and accessors from the
        instances at runtime, we look into the contexts stored with the
        brands, and analyze the scope info to get the names as well as
        context slot indices of them.
      - This patch extends the `PrivatePropertyDescriptor` in the inspector
        protocol to include optional `get` and `set` fields, and make the
        `value` field optional (similar to `PropertyDescriptor`s).
        Private fields or private instance methods are returned in the
        `value` field while private accessors are returned in the `get`
        and/or `set` field. Property previews for the instaces containing
        private instance methods and accessors are also updated similarly,
        although no additional protocol change is necessary since the
        `PropertyPreview` type can already be used to display accessors.
      
      Design doc: https://docs.google.com/document/d/1N91LObhQexnB0eE7EvGe57HsvNMFX16CaWu-XCTnnmY/edit
      
      Bug: v8:9839, v8:8330
      Change-Id: If37090bd23833a18f75deb1249ca5c4405ca2bf2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1934407
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65337}
      963ff849
  18. 27 Nov, 2019 1 commit
    • Leszek Swirski's avatar
      [isolate] Make field getters use a const Isolate* · 42a56e03
      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: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65199}
      42a56e03
  19. 21 Nov, 2019 1 commit
    • Tobias Tebbi's avatar
      [torque] shape: define in-object properties properly · cfab6505
      Tobias Tebbi authored
      This introduces a new keyword "shape" in addition to "class",
      which allows the definition of a type that extends a JSObject
      subclass and specifies one or several maps with statically
      known in-object properties.
      Differences compared to normal classes:
      - Shapes are transient since they specify maps instead of
        instance types.
      - Shapes have a known size.
      - Fields of shapes are always in-object properties. In particular,
        this means that their offset is after kHeaderSize.
      - It's forbidden to inherited from shapes.
      - Since shapes usually specify NativeContext-dependent maps, it's
        not possible to write runtime type-checks for them. Thus this CL
        avoids mapping them to their own TNode type, as the CAST macro
        won't work properly. We had runtime-checks for some of them
        nevertheless, some of them scarily confusing like
        IsJSSloppyArgumentsObject, that actually just checked the instance
        type.
      
      Drive-by cleanups and simplifications:
      - Allow subclassing from non-abstract classes and remove
        @dirtyInstantiatedAbstractClass. This attribute stems from a mis-
        conception of how instance types work, and with this change it
        ceases to have semantic influence.
      - Replace the existing JSArgumentsObject subclasses into two shapes.
        JSArgumentsObjectWithLength had to be removed since shapes don't
        support subclassing.
      - Place kHeaderSize correctly for objects with indexed fields.
      
      Design doc:
      https://docs.google.com/document/d/1zPy2ZYfNFjeEuw6Mz3YJA-GaPGbdcSYam3SrS7ETzRU
      
      Bug: v8:8944
      
      Change-Id: Iabf185ccd27d0900e0890539a7fe9eaa8bf2d50e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1917140
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65108}
      cfab6505
  20. 20 Nov, 2019 1 commit
  21. 18 Nov, 2019 1 commit
  22. 16 Oct, 2019 1 commit
  23. 11 Oct, 2019 2 commits
    • Seth Brenith's avatar
      [torque] Generate instance types · 8c7ae314
      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: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64258}
      8c7ae314
    • Jakob Kummerow's avatar
      Update DescriptorArray and Map to use InternalIndex · d509ed53
      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: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64244}
      d509ed53
  24. 09 Oct, 2019 1 commit
  25. 07 Oct, 2019 1 commit
  26. 29 Aug, 2019 1 commit
    • Seth Brenith's avatar
      [cleanup][torque] Use @generateCppClass in some simple cases, part 2 · a5811358
      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: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#63458}
      a5811358
  27. 28 Aug, 2019 1 commit
    • Z Nguyen-Huu's avatar
      Add new nonextensible element kinds · 1f4bec27
      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: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63432}
      1f4bec27
  28. 15 Jul, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Use @generateCppClass in some simple cases · 14274bb1
      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: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#62719}
      14274bb1
  29. 09 Jul, 2019 1 commit
  30. 28 Jun, 2019 1 commit
  31. 26 Jun, 2019 2 commits
  32. 24 Jun, 2019 1 commit
    • Mathias Bynens's avatar
      [objects] Rename JSValue to JSPrimitiveWrapper · e428dfd7
      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: 's avatarTamer Tas <tmrts@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Mathias Bynens <mathias@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62337}
      e428dfd7
  33. 18 Jun, 2019 1 commit
  34. 17 Jun, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Stricter object field verification, part 2 · 15ea19db
      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: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62228}
      15ea19db
  35. 11 Jun, 2019 3 commits