1. 07 Feb, 2022 1 commit
  2. 30 Sep, 2021 1 commit
  3. 21 Jul, 2021 1 commit
  4. 11 Nov, 2020 1 commit
  5. 17 Aug, 2020 1 commit
    • Z Nguyen-Huu's avatar
      Reland "Improve NumberToString when cache miss and Smi" · 22874998
      Z Nguyen-Huu authored
      This is a reland of 1b35c0fa
      
      Reason for revert: Seems to reliably break a numerics test:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20debug/31516
      
      It was really slow and timeout with debug build run this test
      mjsunit/math-exp-precision with --optimize-for-size because we resize
      cache in CSA. Default this to runtime would avoid the timeout.
      
      Also with --optimize-for-size, we don't have enough space to allocate
      full-size cache so avoid to resize cache in this case.
      
      In my local PC, time for this test decreases as follows.
      Before: 52s
      After: 3s
      
      Original change's description:
      > Improve NumberToString when cache miss and Smi
      >
      > Cache miss was handled in runtime before. This change add fast path for
      > Smi in this case.
      >
      > Perf show 30% improvement for the following example.
      > Before 67 ms
      > After 42 ms
      >
      > const start = new Date();
      > const MAX = 1000000;
      > for (var i = 0; i < MAX; i++) {
      >     i.toString();
      > }
      > const end = new Date();
      > console.log("Time :"+ (end-start));
      >
      > Change-Id: I162e9c35f58551ca6a5a0efe79fb7c7b482a8594
      > Bug: v8:10477
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332866
      > Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#69362}
      
      Bug: v8:10477
      Change-Id: I892a9007210032640d0bf22e61c8e7ad1a4377c4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2351398Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69413}
      22874998
  6. 12 Aug, 2020 2 commits
  7. 20 May, 2020 1 commit
  8. 19 May, 2020 2 commits
  9. 10 Jan, 2020 1 commit
    • Seth Brenith's avatar
      [torque] move more bitfield definitions to Torque · 87c16da5
      Seth Brenith authored
      This change moves the definitions of the bitfield flags used by Symbol
      and Map to Torque. Symbol could directly follow the pattern established
      by SharedFunctionInfo, but Map required some other changes:
      - Until now, Torque bitfield definitions have required unsigned types. I
        thought that this would be the least-surprising behavior, since we
        never sign-extend when decoding bitfield values. However, I believe
        that the amount of churn involved in making ElementsKind be unsigned
        outweighs the benefit we were getting from this restriction (and
        similar difficulties are likely to arise in converting other bitfield
        structs to Torque), so this CL updates Torque to allow signed bitfield
        values.
      - If we try to make Map extend from all of the generated classes that
        define its flags, we end up with class sizing problems because some
        compilers only apply empty base class optimization to the first in a
        row of empty base classes. We could work around this issue by
        generating macros instead of classes, but I took this as an
        opportunity for a minor clean-up instead: rather than having bitfield
        definitions for several different bitfield structs all jumbled
        together in Map, they can be split up. I think this makes the code a
        little easier to follow, but if others disagree I'm happy to implement
        macro generation instead.
      
      Change-Id: Ibf339b0be97f72d740bf1daa8300b471912faeba
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1988934Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#65701}
      87c16da5
  10. 10 Dec, 2019 1 commit
    • Tobias Tebbi's avatar
      [torque] allow allocation of strings · 8ed9be48
      Tobias Tebbi authored
      This CL generalizes and improves how we handle allocations in Torque.
      
      Overview of the changes:
      - Remove obsolete special handling for JSObject classes, since it was
        incomplete: It breaks as soon as slack tracking is active.
      - Handle array initialization using slices.
      - Properly align allocation sizes. This enabled allocating strings.
      - Port AllocateSeq{One,Two}ByteString to Torque, which is much easier
        now than the old CSA code since allocation size alignment and
        large-object space allocation just happen out-of-the-box.
      - Remove obsolete or unnecessary intrinsics, some of them turn into
        macros in the torque_internal namespace.
      - Distinguish between header size and overall size for ClassType,
        make size optional and only defined when it is statically known.
      
      
      Bug: v8:10004 v8:7793
      Change-Id: I623db233e7fb4deed54e8039ae0c24705e9a44e8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1932356Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65397}
      8ed9be48
  11. 11 Nov, 2019 1 commit