1. 07 Sep, 2020 1 commit
  2. 26 Aug, 2020 1 commit
    • Clemens Backes's avatar
      [wasm][fuzzer] Fix BigInt parameters · 2d78b3a7
      Clemens Backes authored
      The fuzzers were calling the compiled function without passing explicit
      arguments. Thus all arguments were converted from the "undefined" value,
      which typically results in a zero value, as expected.
      For BigInt though, it's not allowed to pass "undefined". We have to pass
      a proper BigInt.
      This CL implements this by passing explicit parameter values for all
      parameters.
      
      This effectively unlocks testing BigInt parameters in all fuzzers, thus
      may increase coverage and find new bugs.
      
      R=ahaas@chromium.org
      
      Bug: chromium:1120355
      Change-Id: I4e451d2418eb73d460fa937d1cf95a1ab6c99cf5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377945
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69570}
      2d78b3a7
  3. 20 Mar, 2020 1 commit
  4. 02 Mar, 2020 1 commit
  5. 04 Feb, 2020 1 commit
  6. 15 Nov, 2019 1 commit
  7. 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
  8. 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
  9. 11 Sep, 2019 1 commit
  10. 05 Aug, 2019 1 commit
  11. 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
  12. 12 Jul, 2019 1 commit
  13. 07 Jun, 2019 1 commit
  14. 24 May, 2019 1 commit
  15. 23 May, 2019 2 commits
  16. 21 May, 2019 1 commit
  17. 04 Apr, 2019 1 commit
  18. 29 Mar, 2019 1 commit
  19. 19 Mar, 2019 1 commit
  20. 12 Mar, 2019 1 commit
  21. 13 Feb, 2019 1 commit
  22. 24 Jan, 2019 1 commit
  23. 09 Jan, 2019 1 commit
  24. 08 Jan, 2019 1 commit
  25. 26 Dec, 2018 1 commit
  26. 20 Dec, 2018 1 commit
  27. 19 Dec, 2018 1 commit
  28. 03 Dec, 2018 1 commit
  29. 30 Nov, 2018 2 commits
  30. 28 Nov, 2018 1 commit
  31. 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
  32. 20 Sep, 2018 1 commit
  33. 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
  34. 12 Jul, 2018 1 commit
  35. 02 Jul, 2018 1 commit
  36. 20 Jun, 2018 1 commit