1. 11 Sep, 2019 1 commit
  2. 05 Aug, 2019 1 commit
  3. 29 Jul, 2019 3 commits
    • Clemens Hammacher's avatar
      Reland "[utils] Make BitField final" · 0cabc6a0
      Clemens Hammacher authored
      This is a reland of 658ff200
      
      Original change's description:
      > [utils] Make BitField final
      > 
      > We have hundreds of classes that derive from {BitField} without adding
      > any functionality. This CL switches all such occurrences to 'using'
      > declarations instead.
      > 
      > Before:
      >   class MyBitField : public BitField<int, 6, 4, MyEnum> {};
      > After:
      >   using MyBitField = BitField<int, 6, 4, MyEnum>;
      > 
      > This might reduce compilation time by reducing the number of existing
      > classes.
      > 
      > The old pattern is forbidden now by making {BitField} final.
      > 
      > R=yangguo@chromium.org
      > 
      > Bug: v8:9396, v8:7629
      > Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62956}
      
      Bug: v8:9396, v8:7629
      Change-Id: Ic68541af9d1e8d0340691970922f282b24a9767f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724379Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62959}
      0cabc6a0
    • Clemens Hammacher's avatar
      Revert "[utils] Make BitField final" · 753a07db
      Clemens Hammacher authored
      This reverts commit 658ff200.
      
      Reason for revert: Fails no-i18n bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20noi18n%20-%20debug/27826
      
      Original change's description:
      > [utils] Make BitField final
      > 
      > We have hundreds of classes that derive from {BitField} without adding
      > any functionality. This CL switches all such occurrences to 'using'
      > declarations instead.
      > 
      > Before:
      >   class MyBitField : public BitField<int, 6, 4, MyEnum> {};
      > After:
      >   using MyBitField = BitField<int, 6, 4, MyEnum>;
      > 
      > This might reduce compilation time by reducing the number of existing
      > classes.
      > 
      > The old pattern is forbidden now by making {BitField} final.
      > 
      > R=​yangguo@chromium.org
      > 
      > Bug: v8:9396, v8:7629
      > Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62956}
      
      TBR=yangguo@chromium.org,clemensh@chromium.org
      
      Change-Id: I50234a09c77aa89fdcf1e01c2497cc08d3ac79a8
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9396, v8:7629
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724377Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62958}
      753a07db
    • Clemens Hammacher's avatar
      [utils] Make BitField final · 658ff200
      Clemens Hammacher authored
      We have hundreds of classes that derive from {BitField} without adding
      any functionality. This CL switches all such occurrences to 'using'
      declarations instead.
      
      Before:
        class MyBitField : public BitField<int, 6, 4, MyEnum> {};
      After:
        using MyBitField = BitField<int, 6, 4, MyEnum>;
      
      This might reduce compilation time by reducing the number of existing
      classes.
      
      The old pattern is forbidden now by making {BitField} final.
      
      R=yangguo@chromium.org
      
      Bug: v8:9396, v8:7629
      Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62956}
      658ff200
  4. 12 Jul, 2019 1 commit
  5. 07 Jun, 2019 1 commit
  6. 24 May, 2019 1 commit
  7. 23 May, 2019 2 commits
  8. 21 May, 2019 1 commit
  9. 04 Apr, 2019 1 commit
  10. 29 Mar, 2019 1 commit
  11. 19 Mar, 2019 1 commit
  12. 12 Mar, 2019 1 commit
  13. 13 Feb, 2019 1 commit
  14. 24 Jan, 2019 1 commit
  15. 09 Jan, 2019 1 commit
  16. 08 Jan, 2019 1 commit
  17. 26 Dec, 2018 1 commit
  18. 20 Dec, 2018 1 commit
  19. 19 Dec, 2018 1 commit
  20. 03 Dec, 2018 1 commit
  21. 30 Nov, 2018 2 commits
  22. 28 Nov, 2018 1 commit
  23. 16 Nov, 2018 1 commit
    • Georg Neis's avatar
      [bigint] Make competing read/write operations on bitfield atomic. · f28a7533
      Georg Neis authored
      GC needs to be able to read a bigint's length while the main thread may
      change the length and the sign (bigints are intentionally mutable as
      long as they haven't escaped to user code). Since both values are stored
      in the same bitfield, we need to make these accesses atomic.
      
      Also change right-trimming to not insert a filler when the object is
      in large object space (it makes no sense there).
      
      Bug: v8:8440
      Change-Id: I72a1b6f1eda54566d3cfad554dda1a98ddd61975
      Reviewed-on: https://chromium-review.googlesource.com/c/1337737
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57576}
      f28a7533
  24. 20 Sep, 2018 1 commit
  25. 29 Aug, 2018 1 commit
    • Jakob Kummerow's avatar
      [bigint] Fix NoSideEffectsToString for 32-bit platforms · 9d493179
      Jakob Kummerow authored
      On 32-bit platforms, String::kMaxLength is such that not all BigInts
      can be converted to Strings. NoSideEffectsToString, however, used to
      assume that this conversion always succeeds. This patch adds a check
      for the failure case, and returns "<a very large BigInt>" instead of
      crashing.
      This change is practically unobservable, because actually formatting
      such a huge BigInt to String would take "forever", which is also why
      there is no regression test.
      
      Bug: chromium:876628
      Change-Id: I1eacdc1cce753ac5d9ca66e61e479043ab576e07
      Reviewed-on: https://chromium-review.googlesource.com/1194004Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55491}
      9d493179
  26. 12 Jul, 2018 1 commit
  27. 02 Jul, 2018 1 commit
  28. 20 Jun, 2018 1 commit
  29. 30 Apr, 2018 1 commit
  30. 15 Apr, 2018 1 commit
  31. 14 Apr, 2018 1 commit
    • Jakob Kummerow's avatar
      [ubsan] Change Address typedef to uintptr_t · 2459046c
      Jakob Kummerow authored
      The "Address" type is V8's general-purpose type for manipulating memory
      addresses. Per the C++ spec, pointer arithmetic and pointer comparisons
      are undefined behavior except within the same array; since we generally
      don't operate within a C++ array, our general-purpose type shouldn't be
      a pointer type.
      
      Bug: v8:3770
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: Ib96016c24a0f18bcdba916dabd83e3f24a1b5779
      Reviewed-on: https://chromium-review.googlesource.com/988657
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52601}
      2459046c
  32. 09 Apr, 2018 1 commit
  33. 08 Mar, 2018 3 commits
  34. 01 Mar, 2018 1 commit