1. 19 Oct, 2020 1 commit
  2. 07 Oct, 2020 1 commit
  3. 29 Sep, 2020 1 commit
  4. 23 Jul, 2020 1 commit
  5. 07 Jul, 2020 1 commit
  6. 25 May, 2020 1 commit
  7. 11 May, 2020 1 commit
  8. 18 Mar, 2020 1 commit
  9. 16 Mar, 2020 1 commit
  10. 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
  11. 09 Jan, 2020 2 commits
    • Jakob Kummerow's avatar
      [lookup] Refactor LookupIterator "property or element" creation · 0445fa29
      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: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65672}
      0445fa29
    • 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
  12. 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
  13. 18 Nov, 2019 1 commit
  14. 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
  15. 07 Oct, 2019 1 commit
  16. 10 Sep, 2019 1 commit
  17. 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
  18. 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
  19. 20 Aug, 2019 1 commit
  20. 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
  21. 09 Jul, 2019 1 commit
  22. 28 Jun, 2019 1 commit
  23. 26 Jun, 2019 2 commits
  24. 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
  25. 17 Jun, 2019 2 commits
    • 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
    • Igor Sheludko's avatar
      [ptr-compr] Using TaggedField<> in more places · b9591a58
      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: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62221}
      b9591a58
  26. 11 Jun, 2019 1 commit
  27. 29 May, 2019 1 commit
  28. 28 May, 2019 1 commit
  29. 27 May, 2019 3 commits
    • Benedikt Meurer's avatar
      Reland "[typedarray] Move external/data pointer to JSTypedArray." · 70bd7cf0
      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: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61864}
      70bd7cf0
    • Clemens Hammacher's avatar
      Revert "[typedarray] Move external/data pointer to JSTypedArray." · e4db146a
      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: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61856}
      e4db146a
    • Benedikt Meurer's avatar
      [typedarray] Move external/data pointer to JSTypedArray. · 4b86fea5
      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: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61855}
      4b86fea5
  30. 23 May, 2019 3 commits
    • Benedikt Meurer's avatar
      [cleanup] Remove the `Map::IsDictionaryMap()` method. · 5b46f573
      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: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61770}
      5b46f573
    • Yang Guo's avatar
      Move more relevant files to src/objects · a0c37974
      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: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61769}
      a0c37974
    • Clemens Hammacher's avatar
      [cleanup] Avoid {Object::operator->} · 878ccb33
      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: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarToon 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}
      878ccb33
  31. 21 May, 2019 2 commits