1. 04 Nov, 2020 1 commit
  2. 29 Sep, 2020 1 commit
  3. 28 Sep, 2020 1 commit
  4. 18 Aug, 2020 1 commit
  5. 06 Aug, 2020 1 commit
    • Leszek Swirski's avatar
      [runtime] Move string table off-heap · 1546be9c
      Leszek Swirski authored
      Changes the isolate's string table into an off-heap structure. This
      allows the string table to be resized without allocating on the V8 heap,
      and potentially triggering a GC. This allows existing strings to be
      inserted into the string table without requiring allocation.
      
      This has two important benefits:
      
        1) It allows the deserializer to insert strings directly into the
           string table, rather than having to defer string insertion until
           deserialization completes.
      
        2) It simplifies the concurrent string table lookup to allow resizing
           the table inside the write lock, therefore eliminating the race
           where two concurrent lookups could both resize the table.
      
      The off-heap string table has the following properties:
      
        1) The general hashmap behaviour matches the HashTable, i.e. open
           addressing, power-of-two sized, quadratic probing. This could, of
           course, now be changed.
      
        2) The empty and deleted sentinels are changed to Smi 0 and 1,
           respectively, to make those comparisons a bit cheaper and not
           require roots access.
      
        3) When the HashTable is resized, the old elements array is kept
           alive in a linked list of previous arrays, so that concurrent
           lookups don't lose the data they're accessing. This linked list
           is cleared by the GC, as then we know that all threads are in
           a safepoint.
      
        4) The GC treats the hash table entries as weak roots, and only walks
           them for non-live reference clearing and for evacuation.
      
        5) Since there is no longer a FixedArray to serialize for the startup
           snapshot, there is now a custom serialization of the string table,
           and the string table root is considered unserializable during weak
           root iteration. As a bonus, the custom serialization is more
           efficient, as it skips non-string entries.
      
      As a drive-by, rename LookupStringExists_NoAllocate to
      TryStringToIndexOrLookupExisting, to make it clearer that it returns
      a non-string for the case when the string is an array index. As another
      drive-by, extract StringSet into a separate header.
      
      Bug: v8:10729
      Change-Id: I9c990fb2d74d1fe222920408670974a70e969bca
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339104
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69270}
      1546be9c
  6. 09 Jul, 2020 1 commit
  7. 07 Jul, 2020 1 commit
  8. 02 Jul, 2020 1 commit
  9. 30 Jun, 2020 1 commit
  10. 29 Jun, 2020 2 commits
  11. 25 Jun, 2020 1 commit
  12. 24 Jun, 2020 1 commit
  13. 23 Jun, 2020 1 commit
  14. 22 Jun, 2020 1 commit
  15. 18 Jun, 2020 1 commit
    • Ng Zhi An's avatar
      [wasm-simd][arm] Prototype f32x4.ceil · d9381fd6
      Ng Zhi An authored
      Prototype f32x4.ceil on ARM for both ARM v7 and ARM v8. ARM v8 has
      support for vrintp, and for ARM v7 we fallback to runtime.
      
      Since ARM v8 uses vrintp, which is the same instruction used for F32
      Ceil (scalar), wasm-compiler reuses the Float32Round check, rather than
      creating new F32x4Round optional operators.
      
      Implementation for vrintp (Advanced SIMD version that takes Q
      registers), assembler, disassembler support. Incomplete for now, but
      more will be added as we add other rounding modes.
      
      Bug: v8:10553
      Change-Id: I4563608b9501f6f57c3a8325b17de89da7058a43
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2248779Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68419}
      d9381fd6
  16. 03 Jun, 2020 1 commit
  17. 19 May, 2020 1 commit
  18. 16 Apr, 2020 1 commit
    • Shu-yu Guo's avatar
      [weakrefs] Port FinalizationRegistry cleanup loop to Torque · dbbaccca
      Shu-yu Guo authored
      To avoid shrinking the unregister token map on each pop of the cleared
      cell list, the Torque implementation of the cleanup loop avoids
      shrinking the map until the end of the loop.
      
      To support that, PopClearedCellHoldings is refactored to the Torque
      PopClearedCell which calls the
      JSFinalization::RemoveCellFromUnregisterTokenMap and the runtime
      ShrinkFinalizationRegistryUnregisterTokenMap. The former cannot GC is
      and is implemented in CSA as a fast C call. The latter can GC and is a
      runtime call.
      
      This also incidentally makes uses of FinalizationRegistry without
      unregister token a fast path that doesn't have to leave Torque.
      
      Bug: v8:8179
      Change-Id: Ia0c3c5800d26e31319a818f164f6bd3267355aa6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2137950
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67161}
      dbbaccca
  19. 11 Mar, 2020 3 commits
    • Andreas Haas's avatar
      Reland "[wasm] Do memory.copy bounds check in C++ code" · 126f1ee1
      Andreas Haas authored
      The return value of {memory_copy_wrapper} was defined as {bool} in
      the original CL. When compiled with clang, the full return register is
      written when {true} or {false} is returned. With msvc, however, the
      return value is written as a single byte, without zero-extension. In
      generated code, the full return register is used and therefore stale
      bytes in the return register caused problems.
      
      With this CL the return value is changed to {uint32_t}. This enforces
      zero-extension of the return value and thereby fixes the issue.
      
      R=clemensb@chromium.org
      
      Bug: v8:10281
      Change-Id: I628d01cfd7193fa960a7ccdf0d9fd896f510cd3e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096626
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66666}
      126f1ee1
    • Clemens Backes's avatar
      Revert "[wasm] Do memory.copy bounds check in C++ code" · b8eeb071
      Clemens Backes authored
      This reverts commit c475e704.
      
      Reason for revert: Fails on MSVC: https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/12805
      
      Original change's description:
      > [wasm] Do memory.copy bounds check in C++ code
      > 
      > In the existing implementation we first did a bounds check in generated
      > code, and then called a simple C++ function to do the actual copying.
      > With this CL now we pass the WasmInstanceObject to the C++ function in
      > addition to the memory.copy parameters. Thereby we can do the bounds
      > check in C++, which is much easier, less error prone, and which also
      > speeds up code generation and reduces code size. Performance should not
      > be worse, because we were already doing the call to C++ anyways.
      > 
      > R=​clemensb@chromium.org
      > 
      > Bug: v8:10281
      > Change-Id: I24488d92056f0b5df27a61783a274895bd37cc24
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093434
      > Commit-Queue: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66655}
      
      TBR=ahaas@chromium.org,clemensb@chromium.org
      
      Change-Id: Ic2491f635a292e004f6c95498a045ba102138dc5
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10281
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096623
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66658}
      b8eeb071
    • Andreas Haas's avatar
      [wasm] Do memory.copy bounds check in C++ code · c475e704
      Andreas Haas authored
      In the existing implementation we first did a bounds check in generated
      code, and then called a simple C++ function to do the actual copying.
      With this CL now we pass the WasmInstanceObject to the C++ function in
      addition to the memory.copy parameters. Thereby we can do the bounds
      check in C++, which is much easier, less error prone, and which also
      speeds up code generation and reduces code size. Performance should not
      be worse, because we were already doing the call to C++ anyways.
      
      R=clemensb@chromium.org
      
      Bug: v8:10281
      Change-Id: I24488d92056f0b5df27a61783a274895bd37cc24
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093434
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66655}
      c475e704
  20. 11 Nov, 2019 1 commit
  21. 06 Nov, 2019 2 commits
  22. 05 Nov, 2019 1 commit
  23. 21 Oct, 2019 1 commit
    • Jakob Gruber's avatar
      Reland "[regexp] Guarantee an allocated regexp stack" · 8f58c84e
      Jakob Gruber authored
      This is a reland of 97ed8b27
      
      Original change's description:
      > [regexp] Guarantee an allocated regexp stack
      > 
      > The regexp stack is used during execution of jitted regexp matcher
      > code.  Previously, the stack was initially not present / nullptr, and
      > we had to explicitly check for this condition and bail out in builtin
      > code.
      > 
      > This CL changes behavior to guarantee a present stack by adding a
      > statically-allocated area that is used whenever no
      > dynamically-allocated stack exists.
      > 
      > Change-Id: I52934425ae72cf0e5d13fab2b9d63d37ca76fcf3
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1852126
      > Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#64326}
      
      Change-Id: If345c09bdbfc8dc6b63f016c3f10ffda811bbb6d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1866771
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64401}
      8f58c84e
  24. 17 Oct, 2019 1 commit
  25. 16 Oct, 2019 2 commits
  26. 07 Oct, 2019 1 commit
  27. 30 Sep, 2019 1 commit
  28. 27 Sep, 2019 1 commit
  29. 26 Sep, 2019 1 commit
  30. 04 Sep, 2019 1 commit
  31. 22 Aug, 2019 1 commit
    • Sathya Gunasekaran's avatar
      Revert "[ic] Fix KeyedLoadIC for ArrayIndex access" · 3bd0dc18
      Sathya Gunasekaran authored
      This reverts commit 5c59ba4f.
      
      Reason for revert: requires more thinking 
      
      Original change's description:
      > [ic] Fix KeyedLoadIC for ArrayIndex access
      > 
      > Previously, without support for converting strings to numbers we'd
      > switch to megamorphic state and go to the runtime always to do the
      > conversion causing a performance cliff.
      > 
      > This patch improves the following js-perf-test scores:
      > Object-Lookup-String-Constant-BytecodeHandler: 4.25%
      > Object-Lookup-Index-String-BytecodeHandler: 5.41%
      > 
      > Bug: v8:9449
      > Change-Id: I63787fa84373fc946f1304b0141e48a52a1b4bcb
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1690953
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63293}
      
      TBR=mythria@chromium.org,jyan@ca.ibm.com,gsathya@chromium.org,leszeks@chromium.org,ishell@chromium.org,verwaest@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:9449
      Change-Id: I6b6ad5901175c2e6bbd7516b13e91471adb5776d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1765532Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
      Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63347}
      3bd0dc18
  32. 20 Aug, 2019 1 commit
  33. 13 Aug, 2019 1 commit
  34. 24 Jul, 2019 1 commit
  35. 19 Jul, 2019 1 commit
    • Sathya Gunasekaran's avatar
      Revert "Reland "[regexp] Call the regexp interpreter without CEntry overhead"" · aa478cac
      Sathya Gunasekaran authored
      This reverts commit c2ee4a79.
      
      Reason for revert: webgl_conformance_tests deqp/data/gles2/shaders/conversions.html crashes on Android FYI Release (Nexus 9)
      See https://bugs.chromium.org/p/chromium/issues/detail?id=985624
      
      Original change's description:
      > Reland "[regexp] Call the regexp interpreter without CEntry overhead"
      >
      > This is a reland of d4d28b73
      >
      > Original change's description:
      > > [regexp] Call the regexp interpreter without CEntry overhead
      > >
      > > Previously all RegExp calls went through Runtime_RegExpExec when --regexp-interpret-all was set.
      > >
      > > This CL avoids the runtime overhead by calling into the interpreter directly from the RegExpExec Builtin when the regular expression subject was already compiled to ByteCode (i.e. after the first call).
      > >
      > > Bug: v8:8954
      > > Change-Id: Iae9dfcef3370b772a05b2942305335d592f6f15a
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698391
      > > Commit-Queue: Patrick Thier <pthier@google.com>
      > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#62753}
      >
      > Bug: v8:8954
      > Change-Id: I1f0b6de9c6da65bcb582ddb41a37419116a5c510
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706053
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Commit-Queue: Patrick Thier <pthier@google.com>
      > Cr-Commit-Position: refs/heads/master@{#62794}
      
      TBR=jgruber@chromium.org,petermarshall@chromium.org,pthier@google.com
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:8954, chromium:985624
      Change-Id: I5bc2c397a09979f42f28670f80a5366f2a33d80f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709411
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62824}
      aa478cac