1. 09 Aug, 2021 1 commit
  2. 30 Jun, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Concurrent JSGlobalObjectRef::GetPropertyCell · 76b9d98f
      Jakob Gruber authored
      .. and make JSGlobalObjectRef bg-serialized.
      
      GetPropertyCell was implemented as:
      
       LookupIterator it(holder, isolate, name, LookupIterator::OWN);
       it.TryLookupCachedProperty();
       if (it.state() == LookupIterator::DATA) it.GetPropertyCell();
      
      Due to concurrency requirements, we essentially have to reimplement
      this entire path for use in a concurrent setting:
      
       - Reads in some cases have to use relaxed or acquire semantics.
       - The IsPendingAllocation predicate must be called on some objects
         before reading into them.
       - Repeated reads of the same field must be avoided due to the
         possibility of concurrent modifications.
      
      This CL introduces two new methods:
      
      ConcurrentLookupIterator::TryGetPropertyCell implements the outer
      lookup logic, including the repeated lookup for accessors / cached
      property names.
      
      GlobalDictionary::TryFindPropertyCellForConcurrentLookupIterator is a
      slightly modified HashTable::FindEntry which follows the above rules.
      
      Bug: v8:7790
      Change-Id: Ic9a52da766afdfedce8efcbda92876845a17eed9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2959616Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75467}
      76b9d98f
  3. 21 Apr, 2021 1 commit
  4. 28 Oct, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] generate C++ class definitions per Torque file · 03f60296
      Tobias Tebbi authored
      This CL splits the class definitions per .tq file, to realize the
      following relationship:
      A class defined in src/objects/foo.tq has a C++ definition in
      src/objects/foo.h. Torque then generates:
      
      - torque-generated/src/objects/foo-tq.inc
        An include file (no proper header) to be included in src/objects/foo.h
        containing the Torque-generated C++ class definition.
      
      - torque-generated/src/objects/foo-tq-inl.inc
        An include file (no proper header) to be included in
        src/objects/foo-inl.h containing inline function definitions.
      
      - torque-generated/src/objects/foo-tq.cc
        A source file including src/objects/foo-inl.h that contains non-inline
        function definitions.
      
      Advantages of this approach:
      - Avoid big monolithic headers and preserve the work that went into
        splitting objects.h
      - Moving a definition to Torque keeps everything in the same place
        from a C++ viewpoint, including a fully Torque-generated C++ class
        definition.
      - The Torque-generated include files do not need to be independent
        headers, necessary includes or forward declarations can just be added
        to the headers that include them.
      
      Drive-by changes:
      A bunch of definitions and files had to be moved or created to realize
      a consistent 1:1 relationship between .tq files and C++ headers.
      
      
      Bug: v8:7793
      TBR: hpayer@chromium.org
      Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarSeth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#70853}
      03f60296
  5. 25 Sep, 2020 1 commit
    • Tobias Tebbi's avatar
      Reland "[torque] refactor: use -tq only in filenames derived from .tq files" · 21b58516
      Tobias Tebbi authored
      This is a reland of 64caf2b0
      
      Original change's description:
      > [torque] refactor: use -tq only in filenames derived from .tq files
      >
      > This is to establish a naming rule for Torque-generated files:
      > - If the file is called foo/bar-tq..., then it is derived from a
      >   file foo/bar.tq
      > - Otherwise it doesn't belong to a specific .tq file.
      >
      > So far, we attached -tq to all Torque-generated file names, where it
      > sometimes corresponded to a .tq file name and sometimes not.
      > It is not necessary to add -tq to file names to indicate that they are
      > Torque-generated, since they are already in a directory called
      > torque-generated, and we always refer to them as
      > "torque-generated/filename", so there is no confusion even though some
      > files now have the same name as a corresponding hand-written file, for
      > example factory.cc.
      >
      > TBR: hpayer@chromium.org
      > Bug: v8:7793
      > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70060}
      
      Bug: v8:7793
      TBR: hpayer@chromium.org jgruber@chromium.org
      Change-Id: I6c492bc64aee1ff167e7ef401825eca9097a7f38
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431565
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70137}
      21b58516
  6. 22 Sep, 2020 2 commits
    • Francis McCabe's avatar
      Revert "[torque] refactor: use -tq only in filenames derived from .tq files" · 92aaace1
      Francis McCabe authored
      This reverts commit 64caf2b0.
      
      Reason for revert: Seems to be causing a failure:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/38809?
      
      Original change's description:
      > [torque] refactor: use -tq only in filenames derived from .tq files
      > 
      > This is to establish a naming rule for Torque-generated files:
      > - If the file is called foo/bar-tq..., then it is derived from a
      >   file foo/bar.tq
      > - Otherwise it doesn't belong to a specific .tq file.
      > 
      > So far, we attached -tq to all Torque-generated file names, where it
      > sometimes corresponded to a .tq file name and sometimes not.
      > It is not necessary to add -tq to file names to indicate that they are
      > Torque-generated, since they are already in a directory called
      > torque-generated, and we always refer to them as
      > "torque-generated/filename", so there is no confusion even though some
      > files now have the same name as a corresponding hand-written file, for
      > example factory.cc.
      > 
      > TBR: hpayer@chromium.org
      > Bug: v8:7793
      > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70060}
      
      TBR=jgruber@chromium.org,tebbi@chromium.org
      
      Change-Id: I6960fe540861947536c6ddfc0f4887ea80899fae
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7793
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424486Reviewed-by: 's avatarFrancis McCabe <fgm@chromium.org>
      Commit-Queue: Francis McCabe <fgm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70065}
      92aaace1
    • Tobias Tebbi's avatar
      [torque] refactor: use -tq only in filenames derived from .tq files · 64caf2b0
      Tobias Tebbi authored
      This is to establish a naming rule for Torque-generated files:
      - If the file is called foo/bar-tq..., then it is derived from a
        file foo/bar.tq
      - Otherwise it doesn't belong to a specific .tq file.
      
      So far, we attached -tq to all Torque-generated file names, where it
      sometimes corresponded to a .tq file name and sometimes not.
      It is not necessary to add -tq to file names to indicate that they are
      Torque-generated, since they are already in a directory called
      torque-generated, and we always refer to them as
      "torque-generated/filename", so there is no confusion even though some
      files now have the same name as a corresponding hand-written file, for
      example factory.cc.
      
      TBR: hpayer@chromium.org
      Bug: v8:7793
      Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70060}
      64caf2b0
  7. 18 Mar, 2020 1 commit
  8. 09 Jan, 2020 1 commit
    • Seth Brenith's avatar
      [cleanup] Don't inherit from Tuple2 and Tuple3 · 24c23947
      Seth Brenith authored
      This change updates CachedTemplateObjectMap, BreakPointInfo, and
      BreakPoint to inherit directly from Struct rather than Tuple2 or Tuple3.
      It also removes Tuple3 because nothing else used Tuple3. By avoiding
      tuple types, we get various benefits that Torque can provide:
      - stricter debug verifier functions
      - accessors, cast functions, and printers are generated
      - BreakPoint and BreakPointInfo have different instance types, so you
        can tell them apart at runtime or in a debugger
      
      Change-Id: I9367bc08c6dea55d659fd610f9f6105fd61c907a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1988793Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#65668}
      24c23947
  9. 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
  10. 28 Oct, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Use generated instance types, part 1 · 91e6421c
      Seth Brenith authored
      This change begins making use of the fact that Torque now knows about
      the relationship between classes and instance types, to replace a few
      repetitive lists:
      
      - Instance type checkers (single and range), defined in
        src/objects/instance-type.h
      - Verification dispatch in src/diagnostics/objects-debug.cc
      - Printer dispatch in src/diagnostics/objects-printer.cc
      - Postmortem object type detection in
        tools/debug_helper/get-object-properties.cc
      
      Torque is updated to generate four macro lists for the instance types,
      representing all of the classes separated in two dimensions: classes
      that correspond to a single instance type versus those that have a
      range, and classes that are fully defined in Torque (with fields and
      methods inside '{}') versus those that are only declared. The latter
      distinction is useful because fully-defined classes are guaranteed to
      correspond to real C++ classes, whereas only-declared classes are not.
      
      A few other changes were required to make the lists above work:
      
      - Renamed IsFiller to IsFreeSpaceOrFiller to better reflect what it does
        and avoid conflicts with the new macro-generated IsFiller method. This
        is the part I'm most worried about: I think the new name is an
        improvement for clarity and consistency, but I could imagine someone
        typing IsFiller out of habit and introducing a bug. If we'd prefer to
        keep the name IsFiller, my other idea is to rename FreeSpace to
        VariableSizeFiller and Filler to FixedSizeFiller.
      - Made Tuple3 extend from Struct, not Tuple2, because IsTuple2 is
        expected to check for only TUPLE2_TYPE and not include TUPLE3_TYPE.
      - Normalized the dispatched behavior for BigIntBase and HeapNumber.
      - Added a few new object printers.
      
      Bug: v8:7793
      Change-Id: I5462bb105f8a314baa59bd6ab6ab6215df6f313c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1860314
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64597}
      91e6421c
  11. 11 Oct, 2019 1 commit
    • 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
  12. 07 Oct, 2019 1 commit
  13. 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
  14. 05 Aug, 2019 1 commit
  15. 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
  16. 03 Jun, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Remove some uses of @noVerifier · 29ec0087
      Seth Brenith authored
      Implemented verifiers for the following classes:
      - ExternalString
      - FixedArrayBase
      - JSCollection
      - JSCollectionIterator
      - JSWeakCollection
      - Name
      - SeqString
      - Struct
      
      Removed the following class definitions from Torque, because they're
      just JSObject instances with particular starting maps, as discussed in
      https://crrev.com/c/v8/v8/+/1619146/6/src/builtins/base.tq#459 :
      - JSAccessorPropertyDescriptor
      - JSDataPropertyDescriptor
      - JSIteratorResult
      
      Following similar logic, removed the Torque definition of
      WasmExceptionPackage because it's just an error object that happens to
      have a couple of private-symbol properties.
      
      The following classes should not be defined in Torque because they're
      just a starting state for JSObject, but I'm leaving them for now because
      existing Torque code requires them:
      - JSArgumentsObjectWithLength
      - JSProxyRevocableResult
      
      Bug: v8:9311
      Change-Id: I0336b6be7d02e48e4a8a0f660e24d2c2fa5f5e34
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1637448
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61970}
      29ec0087
  17. 23 May, 2019 1 commit
  18. 16 May, 2019 1 commit
  19. 14 May, 2019 1 commit
  20. 06 Mar, 2019 1 commit
  21. 01 Mar, 2019 2 commits
  22. 13 Feb, 2019 1 commit
  23. 06 Feb, 2019 1 commit
  24. 01 Feb, 2019 2 commits
    • Michael Starzinger's avatar
      Revert "[serializer] share class positions tuple across contexts" · b1eb340d
      Michael Starzinger authored
      This reverts commit a1b431d7.
      
      Reason for revert: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20nosnap%20-%20debug/22809
      
      Original change's description:
      > [serializer] share class positions tuple across contexts
      > 
      > Class positions is a struct that stores the start and end positions of a class
      > literal. It is stored both on class objects, and the template used to
      > instantiate class objects.
      > 
      > The template is reachable from the bytecode array and therefore serialized by
      > the startup serializer. Class objects are context-dependent and therefore
      > serialized by the partial serializer. Serializing class positions from both
      > serializers violates the assumption that we don't serialize any object twice.
      > 
      > R=​gsathya@chromium.org
      > 
      > Bug: v8:8761
      > Change-Id: If22c554cc7396d63998a015454ce0c67a7d2e05c
      > Reviewed-on: https://chromium-review.googlesource.com/c/1444956
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
      > Commit-Queue: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#59292}
      
      TBR=yangguo@chromium.org,mstarzinger@chromium.org,gsathya@chromium.org
      
      Change-Id: I9f3fd1b29b5991b450223f8b27dfc7aa7e5a3171
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8761
      Reviewed-on: https://chromium-review.googlesource.com/c/1450116Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59300}
      b1eb340d
    • Yang Guo's avatar
      [serializer] share class positions tuple across contexts · a1b431d7
      Yang Guo authored
      Class positions is a struct that stores the start and end positions of a class
      literal. It is stored both on class objects, and the template used to
      instantiate class objects.
      
      The template is reachable from the bytecode array and therefore serialized by
      the startup serializer. Class objects are context-dependent and therefore
      serialized by the partial serializer. Serializing class positions from both
      serializers violates the assumption that we don't serialize any object twice.
      
      R=gsathya@chromium.org
      
      Bug: v8:8761
      Change-Id: If22c554cc7396d63998a015454ce0c67a7d2e05c
      Reviewed-on: https://chromium-review.googlesource.com/c/1444956Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59292}
      a1b431d7
  25. 18 Jan, 2019 1 commit
  26. 09 Jan, 2019 1 commit
  27. 26 Dec, 2018 1 commit
  28. 20 Dec, 2018 1 commit
  29. 18 Dec, 2018 1 commit
  30. 17 Dec, 2018 2 commits
  31. 14 Dec, 2018 3 commits