1. 06 Dec, 2019 1 commit
  2. 21 Nov, 2019 1 commit
    • Tobias Tebbi's avatar
      [torque] shape: define in-object properties properly · cfab6505
      Tobias Tebbi authored
      This introduces a new keyword "shape" in addition to "class",
      which allows the definition of a type that extends a JSObject
      subclass and specifies one or several maps with statically
      known in-object properties.
      Differences compared to normal classes:
      - Shapes are transient since they specify maps instead of
        instance types.
      - Shapes have a known size.
      - Fields of shapes are always in-object properties. In particular,
        this means that their offset is after kHeaderSize.
      - It's forbidden to inherited from shapes.
      - Since shapes usually specify NativeContext-dependent maps, it's
        not possible to write runtime type-checks for them. Thus this CL
        avoids mapping them to their own TNode type, as the CAST macro
        won't work properly. We had runtime-checks for some of them
        nevertheless, some of them scarily confusing like
        IsJSSloppyArgumentsObject, that actually just checked the instance
        type.
      
      Drive-by cleanups and simplifications:
      - Allow subclassing from non-abstract classes and remove
        @dirtyInstantiatedAbstractClass. This attribute stems from a mis-
        conception of how instance types work, and with this change it
        ceases to have semantic influence.
      - Replace the existing JSArgumentsObject subclasses into two shapes.
        JSArgumentsObjectWithLength had to be removed since shapes don't
        support subclassing.
      - Place kHeaderSize correctly for objects with indexed fields.
      
      Design doc:
      https://docs.google.com/document/d/1zPy2ZYfNFjeEuw6Mz3YJA-GaPGbdcSYam3SrS7ETzRU
      
      Bug: v8:8944
      
      Change-Id: Iabf185ccd27d0900e0890539a7fe9eaa8bf2d50e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1917140
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65108}
      cfab6505
  3. 15 Nov, 2019 1 commit
  4. 04 Nov, 2019 1 commit
    • Dan Elphick's avatar
      Reland "Reland: [builtins] Move non-JS linkage builtins code objects into RO_SPACE" · 352bbb12
      Dan Elphick authored
      This is a reland of 855591a5
      
      Fixes break in builds that verify ReadOnlyHeap by relaxing the requirement for
      Code objects to be in CODE_SPACE in PagedSpaceObjectIterator::FromCurrentPage.
      
      Original change's description:
      > Reland: [builtins] Move non-JS linkage builtins code objects into RO_SPACE
      >
      > Reland of https://chromium-review.googlesource.com/c/v8/v8/+/1795358.
      >
      > [builtins] Move non-JS linkage builtins code objects into RO_SPACE
      >
      > Creates an allow-list of builtins that can still go in code_space
      > including all TFJ builtins and a small manual list that should be pared
      > down in the future.
      >
      > For builtins that go in RO_SPACE a Code object is created that contains an
      > immediate trap instruction. Generally these Code objects are still no
      > smaller than CODE_SPACE Code objects because of the Code object alignment
      > requirements. This will hopefully be addressed in a follow-up CL either by
      > relaxing them or removing the instruction stream completely.
      >
      > In the snapshot, this reduces code_space from ~152k to ~40k (-112k) and
      > increases by the same amount.
      >
      > Change-Id: I76661c35c7ea5866c1fb16e87e87122b3e3ca0ce
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893336
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#64700}
      
      Change-Id: I4eeb7dab3027b42fa58c5dfb2bad9873e9fff250
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893192
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64728}
      352bbb12
  5. 31 Oct, 2019 2 commits
  6. 18 Oct, 2019 2 commits
    • Sathya Gunasekaran's avatar
      Revert "[builtins] Move non-JS linkage builtins code objects into RO_SPACE" · f1ebde88
      Sathya Gunasekaran authored
      This reverts commit 83f8464f.
      
      Reason for revert: speculative revert for blink linux failure
      https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/1272
      
      Original change's description:
      > [builtins] Move non-JS linkage builtins code objects into RO_SPACE
      > 
      > Creates an allow-list of builtins that can still go in code_space
      > including all TFJ builtins and a small manual list that should be pared
      > down in the future.
      > 
      > For builtins that go in RO_SPACE a Code object is created that contains
      > no code at all (shrinking its size from 96 bytes to 64 bytes on x64),
      > but is there to allow the runtime to continue to work since it expects
      > a Code object.
      > 
      > This reduces code_space from ~152k to ~40k (-112k) and increases
      > read_only_space from 33k to 108k (+75k) in the snapshot.
      > 
      > Bug: v8:7464, v8:9821, v8:9338, v8:8127
      > Change-Id: Icc8bfc722bb267a2bcc17e2f1e27bef7f02f2376
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1795358
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#64377}
      
      TBR=mstarzinger@chromium.org,jgruber@chromium.org,delphick@chromium.org
      
      Change-Id: I4cf38e9370280acdd2de718ca527776ebc509003
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7464, v8:9821, v8:9338, v8:8127
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1868621Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
      Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64383}
      f1ebde88
    • Dan Elphick's avatar
      [builtins] Move non-JS linkage builtins code objects into RO_SPACE · 83f8464f
      Dan Elphick authored
      Creates an allow-list of builtins that can still go in code_space
      including all TFJ builtins and a small manual list that should be pared
      down in the future.
      
      For builtins that go in RO_SPACE a Code object is created that contains
      no code at all (shrinking its size from 96 bytes to 64 bytes on x64),
      but is there to allow the runtime to continue to work since it expects
      a Code object.
      
      This reduces code_space from ~152k to ~40k (-112k) and increases
      read_only_space from 33k to 108k (+75k) in the snapshot.
      
      Bug: v8:7464, v8:9821, v8:9338, v8:8127
      Change-Id: Icc8bfc722bb267a2bcc17e2f1e27bef7f02f2376
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1795358
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64377}
      83f8464f
  7. 25 Sep, 2019 1 commit
  8. 23 Aug, 2019 1 commit
    • Dan Elphick's avatar
      [compiler] Skip creating unneeded objects for lazy source positions · 735f3a68
      Dan Elphick authored
      This changes Compiler::CollectSourcePositions to skip finalization of
      the BytecodeArray, constant table, handler table, ScopeInfos as well as
      internalization of Ast values since only the source position table is
      used and the others will be collected soon after by the GC.
      
      It will also now avoid recompiling inner functions that would otherwise
      be eagerly compiled.
      
      BytecodeArrayWriter::ToBytecodeArray has been changed to never populate
      the source_position_table.
      
      Bug: v8:8510
      Change-Id: I2db2f2da6b48fde11f17a20d017c1a54c0a34fc2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763538
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63365}
      735f3a68
  9. 05 Aug, 2019 1 commit
  10. 30 Jul, 2019 1 commit
    • Georgia Kouveli's avatar
      [arm64] Reduce code size of deoptimization exits · 207d6b35
      Georgia Kouveli authored
      Do not pass the deoptimization index in a register, instead infer it
      from the address we made the deoptimization call from. This makes the
      deoptimization exit sequence one instruction long instead of two.
      
      This requires emitting all deoptimization exits at the end of the
      function in a contiguous block, making sure no constant or veneer
      pools are emitted in between. This means that soft deoptimizations
      require an additional branch to the end of the function, which
      counteracts the removal of the move instruction, however soft
      deoptimizations are rare compared to eager and lazy ones.
      
      This reduces the code size of optimised functions for benchmarks like
      Octane and ARES-6 by about 4%.
      
      Change-Id: I771f9104a07de7931a4bb9c5836e25fb55b1a2a4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714876
      Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62991}
      207d6b35
  11. 29 Jul, 2019 4 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
    • Michael Starzinger's avatar
      [wasm] Make constructed {WebAssembly.Function} callable. · ba77172b
      Michael Starzinger authored
      This makes function objects constructed via the {WebAssembly.Function}
      constructor callable directly from JavaScript (not just from within
      WebAssembly modules). Semantics are as if the function performed the
      transition JS-to-Wasm and then Wasm-to-JS in sequence.
      
      R=clemensh@chromium.org
      TEST=mjsunit/wasm/type-reflection
      BUG=v8:7742
      
      Change-Id: Ic7dcf36ccfda1b473f2541e49419f4d2ee38bc2c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720809
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62953}
      ba77172b
  12. 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
  13. 08 Jul, 2019 1 commit
  14. 30 May, 2019 1 commit
  15. 23 May, 2019 1 commit
  16. 21 May, 2019 1 commit
  17. 09 May, 2019 1 commit
  18. 08 May, 2019 1 commit
  19. 25 Apr, 2019 1 commit
  20. 10 Apr, 2019 4 commits
  21. 09 Apr, 2019 1 commit
  22. 08 Apr, 2019 2 commits
  23. 04 Apr, 2019 1 commit
  24. 29 Mar, 2019 1 commit
  25. 28 Mar, 2019 1 commit
  26. 25 Mar, 2019 1 commit
    • Mythri's avatar
      [lite] Allocate feedback vectors lazily · 7629afdb
      Mythri authored
      Allocate feedback vectors lazily when the function's interrupt budget has
      reached a specified threshold. This cl introduces a new field in the
      ClosureFeedbackCellArray to track the interrupt budget for allocating
      feedback vectors. Using the interrupt budget on the bytecode array could
      cause problems when there are closures across native contexts and we may
      delay allocating feedback vectors in one of them causing unexpected
      performance cliffs. In the long term we may want to remove interrupt budget
      from bytecode array and use context specific budget for tiering up decisions
      as well.
      
      Bug: v8:8394
      Change-Id: Ia8fbb71f5e8543a92f14c44aa762973da82d445c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1520719
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60450}
      7629afdb
  27. 12 Mar, 2019 1 commit
  28. 06 Mar, 2019 1 commit
  29. 04 Mar, 2019 1 commit
  30. 27 Feb, 2019 2 commits