1. 11 Nov, 2019 1 commit
  2. 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
  3. 08 Oct, 2019 1 commit
  4. 06 Aug, 2019 1 commit
  5. 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
  6. 26 Jun, 2019 1 commit
  7. 24 Jun, 2019 1 commit
  8. 23 May, 2019 1 commit
  9. 21 May, 2019 2 commits
  10. 12 Mar, 2019 1 commit
    • Georg Neis's avatar
      [csa] Make JSProxy's CheckGetSetTrapResult bailout for certain names · b9962a9a
      Georg Neis authored
      The TryGetOwnProperty code supports only unique names that are not
      array indices. Unfortunately, this is neither obvious from its type,
      nor from its comment, nor from its code.
      
      ProxiesCodeStubAssembler::CheckHasTrapResult violated the assumption
      and was already fixed a few days ago. This CL fixes
      CheckGetSetTrapResult and improves our code documentation in the
      form of comments and assertions. Concretely:
      
      - Add CodeStubAssembler::IsUniqueName and IsUniqueNameNoIndex
      - Use IsUniqueNameNoIndex in CheckGetSetTrapResult to guard
        TryGetOwnProperty (bailout to runtime if not satisfied).
      - Similarly, use IsUniqueNameNoIndex to simplify the previous fix in
        CheckHasTrapResult.
      - Add a IsUniqueNameNoIndex CSA_ASSERT to TryGetOwnProperty and a few
        other places to avoid such bugs in the future.
      - Add a IsUniqueName CSA_ASSERT to a few places where we apparently
        expect unique names (I don't know if those allow indices or not).
      - Add a DCHECK to Name::IsUniqueName to ensure and document that this
        shortcut version is equivalent to HeapObject::IsUniqueName.
      
      Bug: chromium:937618
      Change-Id: Id4a18ab2a0e9c7591b087dd0c9fe018aa9b9ef3a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1514732
      Auto-Submit: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60196}
      b9962a9a
  11. 22 Feb, 2019 1 commit
  12. 15 Feb, 2019 1 commit
  13. 13 Feb, 2019 1 commit
  14. 09 Jan, 2019 1 commit
  15. 20 Dec, 2018 1 commit
  16. 27 Nov, 2018 1 commit
  17. 26 Nov, 2018 1 commit
    • Marja Hölttä's avatar
      [iwyu] Include heap-inl.h less. · 0453d418
      Marja Hölttä authored
      - Remove heap-inl.h includes from places where it looked unnecessary. (This is a
        non-scientific approach, because it's probably pulled in indirectly anyway.)
      
      - Annotate places which include heap-inl.h because they need heap/ internals.
      
      - ACCESSORS legitimately needs heap-inl.h because of Heap::FromWritableHeapObject.
      
      - Add includes to heap/heap-write-barrier(-inl).h
      
      - A bunch of IWYU fixes discovered when working on this CL (includes which were
        missing because heap-inl.h pulls them in indirectly).
      
      BUG=v8:7490,v8:8238,v8:8499
      
      Change-Id: I00f9a74d430f13d7c080dca77a92b03bcca7ef96
      Reviewed-on: https://chromium-review.googlesource.com/c/1349241Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57814}
      0453d418
  18. 06 Nov, 2018 1 commit
  19. 13 Sep, 2018 1 commit
    • Benedikt Meurer's avatar
      [objects] Change String::length field to uint32_t. · c7a0049e
      Benedikt Meurer authored
      This changes the Name::hash_field and Symbol::flags to uint32_t as
      well, so that both Symbols and Strings consume one fewer word on 64-bit
      architectures now. More importantly the access to String::length is
      always a 32-bit field load now, even with 31-bit Smis (i.e. on ARM or
      on 64-bit with pointer compression), so the access should be faster.
      
      Bug: v8:7065, v8:8171
      Change-Id: I1a38f4470d62fbeba2b3bc5fcf4ecdbada7d6b8a
      Tbr: ulan@chromium.org, yangguo@chromium.org, ishell@chromium.org
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/1224432Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55861}
      c7a0049e
  20. 12 Sep, 2018 6 commits
    • Sathya Gunasekaran's avatar
      Revert "Reland "[objects] Change String::length field to uint32_t."" · 350dfb62
      Sathya Gunasekaran authored
      This reverts commit a03cec2c.
      
      Reason for revert: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/21320
      
      Original change's description:
      > Reland "[objects] Change String::length field to uint32_t."
      > 
      > This is a reland of 1f1eb625, the
      > breakage on the GCStress bot seems to be unrelated (maybe flushed
      > out by this change). We decided to reland to figure out whether it's
      > a random flake or really triggered by this particular change.
      > 
      > Original change's description:
      > > [objects] Change String::length field to uint32_t.
      > >
      > > This changes the Name::hash_field and Symbol::flags to uint32_t as
      > > well, so that both Symbols and Strings consume one fewer word on 64-bit
      > > architectures now. More importantly the access to String::length is
      > > always a 32-bit field load now, even with 31-bit Smis (i.e. on ARM or
      > > on 64-bit with pointer compression), so the access should be faster.
      > >
      > > Bug: v8:7065, v8:8171
      > > Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
      > > Change-Id: I5523deb1f84ece91fa2fea775d50318bd1300493
      > > Reviewed-on: https://chromium-review.googlesource.com/1221288
      > > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#55825}
      > 
      > Bug: v8:7065, v8:8171
      > Tbr: tebbi@chromium.org, yangguo@chromium.org, ishell@chromium.org, ulan@chromium.org
      > Change-Id: I2be24ac018591c04c826e7e8db82e007b738d156
      > Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
      > Reviewed-on: https://chromium-review.googlesource.com/1222308
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#55838}
      
      TBR=yangguo@chromium.org,tebbi@chromium.org,ishell@chromium.org,bmeurer@chromium.org
      
      Change-Id: Ic741c3d407d4257a8c86b3082b9a19e33dc89215
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7065, v8:8171
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/1222368Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55839}
      350dfb62
    • Benedikt Meurer's avatar
      Reland "[objects] Change String::length field to uint32_t." · a03cec2c
      Benedikt Meurer authored
      This is a reland of 1f1eb625, the
      breakage on the GCStress bot seems to be unrelated (maybe flushed
      out by this change). We decided to reland to figure out whether it's
      a random flake or really triggered by this particular change.
      
      Original change's description:
      > [objects] Change String::length field to uint32_t.
      >
      > This changes the Name::hash_field and Symbol::flags to uint32_t as
      > well, so that both Symbols and Strings consume one fewer word on 64-bit
      > architectures now. More importantly the access to String::length is
      > always a 32-bit field load now, even with 31-bit Smis (i.e. on ARM or
      > on 64-bit with pointer compression), so the access should be faster.
      >
      > Bug: v8:7065, v8:8171
      > Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: I5523deb1f84ece91fa2fea775d50318bd1300493
      > Reviewed-on: https://chromium-review.googlesource.com/1221288
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#55825}
      
      Bug: v8:7065, v8:8171
      Tbr: tebbi@chromium.org, yangguo@chromium.org, ishell@chromium.org, ulan@chromium.org
      Change-Id: I2be24ac018591c04c826e7e8db82e007b738d156
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/1222308Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55838}
      a03cec2c
    • Benedikt Meurer's avatar
      Revert "Reland "[objects] Change String::length field to uint32_t."" · bd69d64d
      Benedikt Meurer authored
      This reverts commit df6157ae.
      
      Reason for revert: trybots didn't rerun :-/
      
      Original change's description:
      > Reland "[objects] Change String::length field to uint32_t."
      > 
      > This is a reland of 1f1eb625, the
      > breakage on the GCStress bot seems to be unrelated (maybe flushed
      > out by this change). We decided to reland to figure out whether it's
      > a random flake or really triggered by this particular change.
      > 
      > Original change's description:
      > > [objects] Change String::length field to uint32_t.
      > >
      > > This changes the Name::hash_field and Symbol::flags to uint32_t as
      > > well, so that both Symbols and Strings consume one fewer word on 64-bit
      > > architectures now. More importantly the access to String::length is
      > > always a 32-bit field load now, even with 31-bit Smis (i.e. on ARM or
      > > on 64-bit with pointer compression), so the access should be faster.
      > >
      > > Bug: v8:7065, v8:8171
      > > Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
      > > Change-Id: I5523deb1f84ece91fa2fea775d50318bd1300493
      > > Reviewed-on: https://chromium-review.googlesource.com/1221288
      > > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#55825}
      > 
      > Tbr: tebbi@chromium.org, yangguo@chromium.org, ishell@chromium.org
      > Bug: v8:7065, v8:8171
      > Change-Id: I3c7d0b00abb15fa98ab622f9ecd8602fc798cbc3
      > Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
      > Reviewed-on: https://chromium-review.googlesource.com/1221290
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#55836}
      
      TBR=ulan@chromium.org,yangguo@chromium.org,tebbi@chromium.org,ishell@chromium.org,bmeurer@chromium.org
      
      Change-Id: Ieaf3be31166abb02e37370ad846c38fa3d114693
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7065, v8:8171
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/1222306Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55837}
      bd69d64d
    • Benedikt Meurer's avatar
      Reland "[objects] Change String::length field to uint32_t." · df6157ae
      Benedikt Meurer authored
      This is a reland of 1f1eb625, the
      breakage on the GCStress bot seems to be unrelated (maybe flushed
      out by this change). We decided to reland to figure out whether it's
      a random flake or really triggered by this particular change.
      
      Original change's description:
      > [objects] Change String::length field to uint32_t.
      >
      > This changes the Name::hash_field and Symbol::flags to uint32_t as
      > well, so that both Symbols and Strings consume one fewer word on 64-bit
      > architectures now. More importantly the access to String::length is
      > always a 32-bit field load now, even with 31-bit Smis (i.e. on ARM or
      > on 64-bit with pointer compression), so the access should be faster.
      >
      > Bug: v8:7065, v8:8171
      > Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: I5523deb1f84ece91fa2fea775d50318bd1300493
      > Reviewed-on: https://chromium-review.googlesource.com/1221288
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#55825}
      
      Tbr: tebbi@chromium.org, yangguo@chromium.org, ishell@chromium.org
      Bug: v8:7065, v8:8171
      Change-Id: I3c7d0b00abb15fa98ab622f9ecd8602fc798cbc3
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/1221290
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55836}
      df6157ae
    • Leszek Swirski's avatar
      Revert "[objects] Change String::length field to uint32_t." · 4bbb7c4e
      Leszek Swirski authored
      This reverts commit 1f1eb625.
      
      Reason for revert: GC Stress failure (https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/21311) 
      
      Original change's description:
      > [objects] Change String::length field to uint32_t.
      > 
      > This changes the Name::hash_field and Symbol::flags to uint32_t as
      > well, so that both Symbols and Strings consume one fewer word on 64-bit
      > architectures now. More importantly the access to String::length is
      > always a 32-bit field load now, even with 31-bit Smis (i.e. on ARM or
      > on 64-bit with pointer compression), so the access should be faster.
      > 
      > Bug: v8:7065, v8:8171
      > Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: I5523deb1f84ece91fa2fea775d50318bd1300493
      > Reviewed-on: https://chromium-review.googlesource.com/1221288
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#55825}
      
      TBR=yangguo@chromium.org,tebbi@chromium.org,ishell@chromium.org,bmeurer@chromium.org
      
      Change-Id: I73f3200902f9d52e5664d48c938e37d9dfb7bce7
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7065, v8:8171
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/1221706Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55826}
      4bbb7c4e
    • Benedikt Meurer's avatar
      [objects] Change String::length field to uint32_t. · 1f1eb625
      Benedikt Meurer authored
      This changes the Name::hash_field and Symbol::flags to uint32_t as
      well, so that both Symbols and Strings consume one fewer word on 64-bit
      architectures now. More importantly the access to String::length is
      always a 32-bit field load now, even with 31-bit Smis (i.e. on ARM or
      on 64-bit with pointer compression), so the access should be faster.
      
      Bug: v8:7065, v8:8171
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: I5523deb1f84ece91fa2fea775d50318bd1300493
      Reviewed-on: https://chromium-review.googlesource.com/1221288
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55825}
      1f1eb625
  21. 12 Jul, 2018 1 commit
  22. 21 Jun, 2018 1 commit
  23. 24 May, 2018 1 commit
  24. 22 Feb, 2018 1 commit
  25. 28 Nov, 2017 1 commit
  26. 13 Sep, 2017 1 commit
  27. 01 Aug, 2017 1 commit
    • Benedikt Meurer's avatar
      [builtins] Speed-up Object.prototype.toString. · 31800120
      Benedikt Meurer authored
      The @@toStringTag lookup in Object.prototype.toString causes quite a
      lot of overhead and oftentimes dominates the builtin performance. These
      lookups are almost always negative, especially for primitive values,
      and Object.prototype.toString is often used to implement predicates
      (like in Node core or in AngularJS), so having a way to skip the
      negative lookup yields big performance gains.
      
      This CL introduces a "MayHaveInterestingSymbols" bit on every map,
      which says whether instances with this map may have an interesting
      symbol. Currently only @@toStringTag is considered an interesting
      symbol, but we can extend that in the future.
      
      In the Object.prototype.toString we can use the interesting symbols
      bit to do a quick check on the prototype chain to see if there are
      any maps that might have the @@toStringTag, and if not, we can just
      immediately return the result, which is very fast because it's derived
      from the instance type. This also avoids the ToObject conversions for
      primitive values, which is important, since this causes unnecessary
      GC traffic and in for example AngularJS, strings are also often probed
      via the Object.prototype.toString based predicates.
      
      This boosts Speedometer/AngularJS by over 3% and Speedometer overall
      by up to 1%. On the microbenchmark from the similar SpiderMonkey bug
      (https://bugzilla.mozilla.org/show_bug.cgi?id=1369042), we go from
      roughly 450ms to 70ms, which corresponds to a 6.5x improvement.
      
      ```
      function f() {
          var res = "";
          var a = [1, 2, 3];
          var toString = Object.prototype.toString;
          var t = new Date;
          for (var i = 0; i < 5000000; i++)
      	res = toString.call(a);
          print(new Date - t);
          return res;
      }
      f();
      ```
      
      The design document at https://goo.gl/e8CruQ has some additional
      data points.
      
      TBR=ulan@chromium.org
      
      Bug: v8:6654
      Change-Id: I31932cf41ecddad079d294e2c322a852af0ed244
      Reviewed-on: https://chromium-review.googlesource.com/593620
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47034}
      31800120
  28. 16 Jun, 2017 1 commit
  29. 12 Jun, 2017 1 commit