1. 02 May, 2022 4 commits
  2. 01 May, 2022 1 commit
  3. 30 Apr, 2022 1 commit
  4. 29 Apr, 2022 18 commits
  5. 28 Apr, 2022 16 commits
    • Junliang Yan's avatar
      ppc64: [baseline] port PrologueFillFrame and VerifyFrameSize · 19e05d6d
      Junliang Yan authored
      Change-Id: I23376b2ad0dc8616048f8c9c7122d5bf38fa70d8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3615013
      Commit-Queue: Junliang Yan <junyan@redhat.com>
      Reviewed-by: 's avatarMilad Farazmand <mfarazma@redhat.com>
      Cr-Commit-Position: refs/heads/main@{#80269}
      19e05d6d
    • Michael Lippautz's avatar
      [handles] Simplify GlobalHandles 2nd pass callback handling · cf0d4647
      Michael Lippautz authored
      - Rely on GCCallbacksScope to avoid nesting callbacks.
      - Use a single entrypoint consistently for all callsites.
      
      Change-Id: I6be1f749a2d6bfc9d5db4c84c753e9176472bce2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605821Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80268}
      cf0d4647
    • Adam Klein's avatar
      Revert "[heap] Refactor atomic marking phase" · 349d4513
      Adam Klein authored
      This reverts commit a3f66927.
      
      Reason for revert: test failures on TSAN/no-concurrent-marking bot:
      https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20no-concurrent-marking/8549/overview
      
      Original change's description:
      > [heap] Refactor atomic marking phase
      >
      > The atomic marking phase was organized in many distinct smaller
      > phases. In particular, before http://crrev.com/c/3584115 the marking
      > phase split into two large separate phases.
      >
      > This CL reorganizes marking into two phases that perform regular V8
      > heap marking, Oilpan, and ephemerons:
      > - A parallel phase that likely drains all marking worklists;
      > - A single-threaded final phase to catch any left overs;
      >
      > This avoids artificial splitting in phases and also avoids repeated
      > starting and joining of jobs.
      >
      > Change-Id: I5cccfc5777837d9ece10d8f4925781bf2d07d9da
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3602507
      > Reviewed-by: Omer Katz <omerkatz@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#80265}
      
      Change-Id: I4838e9316bd30f8a0b78fa6a27820d3457e1e579
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3614972
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Auto-Submit: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80267}
      349d4513
    • Junliang Yan's avatar
      ppc64: [baseline] implement Switch function · 48123d6b
      Junliang Yan authored
      Change-Id: Iae749161f5a6f2347a64f45579d9bd9d5e0ccaf6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3613387Reviewed-by: 's avatarMilad Farazmand <mfarazma@redhat.com>
      Commit-Queue: Junliang Yan <junyan@redhat.com>
      Cr-Commit-Position: refs/heads/main@{#80266}
      48123d6b
    • Michael Lippautz's avatar
      [heap] Refactor atomic marking phase · a3f66927
      Michael Lippautz authored
      The atomic marking phase was organized in many distinct smaller
      phases. In particular, before http://crrev.com/c/3584115 the marking
      phase split into two large separate phases.
      
      This CL reorganizes marking into two phases that perform regular V8
      heap marking, Oilpan, and ephemerons:
      - A parallel phase that likely drains all marking worklists;
      - A single-threaded final phase to catch any left overs;
      
      This avoids artificial splitting in phases and also avoids repeated
      starting and joining of jobs.
      
      Change-Id: I5cccfc5777837d9ece10d8f4925781bf2d07d9da
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3602507Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80265}
      a3f66927
    • Milad Fa's avatar
      PPC: [builtins] Add 'RestartFrameTrampoline' · 692aeb27
      Milad Fa authored
      Port b0118171
      
      Original Commit Message:
      
          This CL adds a new builtin called "RestartFrameTrampoline". This
          trampoline is relatively simple: It leaves the current frame and
          re-invokes the function. This essentially restarts the function and
          is one of the key components required to bring back the "Restart
          frame" DevTools debugging feature.
      
          The builtin is closely related to the "FrameDropperTrampoline"
          removed in the CL https://crrev.com/c/2854750. The key difference
          is that the "FrameDropperTrampoline" dropped to an "arbitrary"
          frame pointer before restarting the function (arbitrary in the
          sense that it was provided as an argument). This caused issues
          as the feature was implemented in a way that the frame pointer
          wasn't necessarily valid anymore.
      
          In comparison, the "RestartFrameTrampoline" relies on the V8
          unwinder to drop it in the correct frame first and is then
          invoked via either the CEntry stub or the deoptimizer
          (see design doc for details).
      
      R=szuend@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
      BUG=
      LOG=N
      
      Change-Id: Id742eeaa59a540ec206a92308fb72bb50413e267
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3613391Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
      Cr-Commit-Position: refs/heads/main@{#80264}
      692aeb27
    • Leszek Swirski's avatar
      [maglev] Add a write barrier to StoreField · cb4fb3b5
      Leszek Swirski authored
      StoreField wasn't emitting a write barrier after performing the store,
      leading to the usual set of hard-to-debug issues. Now it does.
      
      The write barrier requires some of its registers to be in fixed
      locations, and others to be clobberable. Thsi patch extends the
      temporaries mechanism to allow requesting a specific temporary, in this
      case for the slot address scratch register.
      
      Bug: v8:7700
      Change-Id: I506856071e0f44feafb98c2685ef1b3362b0e41e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3613388
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80263}
      cb4fb3b5
    • Dominik Inführ's avatar
      Reland "[heap] Store size with invalidated object" · 23b2d571
      Dominik Inführ authored
      This is a reland of commit 5d235def
      
      The previous version of this CL got reverted because the cached
      size of an invalidated object wasn't up-to-date when performing a GC.
      
      Not all size changes go through NotifyObjectLayoutChange, so
      https://crrev.com/c/3607992 introduced NotifyObjectSizeChange as a
      bottleneck for object size changes/right-trimming. This method is
      now used to update the size of invalidated objects.
      
      Original change's description:
      > [heap] Store size with invalidated object
      >
      > When updating pointers during a full GC, a page might not be swept
      > already. In such cases there might be invalid objects and slots recorded
      > in free memory. Updating tagged slots in free memory is fine even though
      > it is superfluous work.
      >
      > However, the GC also needs to calculate the size of potentially dead
      > invalid objects in order to be able to check whether a slot is within
      > that object. But since that object is dead, its map might be dead as
      > well which makes size calculation impossible on such objects. The CL
      > changes this to cache the size of invalid objects. A follow-up CL will
      > also check the marking bit of invalid objects.
      >
      > Bug: v8:12578, chromium:1316289
      > Change-Id: Ie773d0862a565982957e0dc409630d76552d1a32
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3599482
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Jakob Linke <jgruber@chromium.org>
      > Reviewed-by: Patrick Thier <pthier@chromium.org>
      > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#80169}
      
      Bug: v8:12578, chromium:1316289
      Change-Id: I1f7c6070b8e7d116aeb1a8d03d4f87927ab40872
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3608632Reviewed-by: 's avatarJakob Linke <jgruber@chromium.org>
      Reviewed-by: 's avatarPatrick Thier <pthier@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80262}
      23b2d571
    • Victor Gomes's avatar
      [maglev] Generic CreateEmptyArrayLiteral node · 56adca8e
      Victor Gomes authored
      We should just call the builtin while we don't have inlined
      allocations.
      
      Bug: v8:7700
      Change-Id: I6da605cc756b0f44fb1366e90e6c0dac60ae9beb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3613326
      Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Victor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80261}
      56adca8e
    • Camillo Bruni's avatar
      [snapshot] Reduce startup snapshot checksum check overhead · 8a744da3
      Camillo Bruni authored
      Avoid calculating the checksum on every snapshot deserialization.
      
      - Desktop: by default only in release
      - Android: once per process
      
      Most snapshot corruptions happen on android devices but there we also
      have the highest overhead from calculating the checksum.
      
      Findings doc: https://docs.google.com/document/d/e/2PACX-1vQWdJjrZpTL5VjbP_LHH-qQj-9vcmuLez93WPZhoacJT2bTXfCAdJpbexfJWP9jrAI5ek_416uZE6_W/pub
      
      Bug: v8:12195
      Change-Id: Ic7f2f45a9e8ade31c3774a7b659d9c30769e2b44
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3583983Reviewed-by: 's avatarJakob Linke <jgruber@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80260}
      8a744da3
    • Igor Sheludko's avatar
      Reland "[rwx][mac] Support fast W^X permission switching on Apple Silicon (M1)" · 449ece38
      Igor Sheludko authored
      This is a reland of commit 9d31f866
      There were issues with --future flag implications on M1.
      
      Original change's description:
      > [rwx][mac] Support fast W^X permission switching on Apple Silicon (M1)
      >
      > ... for V8 code space. The feature is currently disabled.
      >
      > In order to use fast W^X permission switching we must allocate
      > executable pages with readable writable executable permissions (RWX).
      > However, MacOS on ARM64 ("Apple M1"/Apple Silicon) prohibits further
      > permission changing of RWX memory pages. This means that the code page
      > headers must be allocated with RWX permissions too because otherwise
      > it wouldn't be possible to allocate a large code page over the freed
      > regular code page and vice versa.
      >
      > When enabled, the new machinery works as follows:
      >
      > 1) when memory region is reserved for allocating executable pages, the
      >    whole region is committed with RWX permissions and then decommitted,
      > 2) since reconfiguration of RWX page permissions is not allowed on
      >    MacOS on ARM64 ("Apple M1"/Apple Silicon), there must be no attempts
      >    to change them,
      > 3) the request to set RWX permissions in the executable page region
      >    just recommits the pages without changing permissions (see (1), they
      >    were already allocated as RWX and then discarded),
      > 4) in order to make executable pages inaccessible one must use
      >    OS::DiscardSystemPages() instead of OS::DecommitPages() or
      >    setting permissions to kNoAccess because the latter two are not
      >    allowed by the MacOS (see (2)).
      > 5) since code space page headers are allocated as RWX pages it's also
      >    necessary to switch between W^X modes when updating the data in the
      >    page headers (i.e. when marking, updating stats, wiring pages in
      >    lists, etc.). The new CodePageHeaderModificationScope class is used
      >    in the respective places. On unrelated configurations it's a no-op.
      >
      > The fast permission switching can't be used for V8 configuration with
      > enabled pointer compression and disabled external code space because
      > a) the pointer compression cage has to be reserved with MAP_JIT flag
      >    which is too expensive,
      > b) in case of shared pointer compression cage if the code range will
      >    be deleted while the cage is still alive then attempt to configure
      >    permissions of pages that were previously set to RWX will fail.
      >
      > This also CL extends the unmapper unit tests with permissions tracking
      > for discarded pages.
      >
      > Bug: v8:12797
      > Change-Id: Idb28cbc481306477589eee9962d2e75167d87c61
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3579303
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Commit-Queue: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#80238}
      
      Bug: v8:12797
      Change-Id: I0fe86666f31bad37d7074e217555c95900d2afba
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610433Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80259}
      449ece38
    • Benoît Lizé's avatar
      [base/platform] Simplify /proc/self/maps parsing · 03b69480
      Benoît Lizé authored
      There are three ways to parse /proc/self/maps in platform-linux.cc,
      remove one to use common code. In the process, add a unit test, and fix
      some issues in the latest iteration of /proc/self/maps parsing.
      
      Change-Id: I4701ea49fe8cce53aea0179e194dc48fbebb2ff5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605226
      Commit-Queue: Benoit Lize <lizeb@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80258}
      03b69480
    • Omer Katz's avatar
      cppgc: Revise WeakContainerTest.* · cf6ad387
      Omer Katz authored
      For some reason the compiler was optimizing away the reference to the
      object in WeakContainerTest.ConservativeGCTracesWeakContainer and thus
      not finding it conservatively.
      This CL revises the tests such that the compiler is no longer able to
      optimize references away.
      
      Bug: v8:12824
      Change-Id: Ie598a1cf1124c2983a6c61fd4e990734d36f5832
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610627Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Omer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarAnton Bikineev <bikineev@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80257}
      cf6ad387
    • Camillo Bruni's avatar
      [flags] Avoid endless lops when enforcing flag implications · 42138ac2
      Camillo Bruni authored
      Change-Id: Ide8935a02cb64134c3bdeb8b3e38e9a6e043e13c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610432Reviewed-by: 's avatarPatrick Thier <pthier@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80256}
      42138ac2
    • Victor Gomes's avatar
      [maglev] Float64 box/unbox elision · 4837f372
      Victor Gomes authored
      - Supports Float64 Add for SmiAdd bytecode
      - Adds a Float64Constant and ChangeInt32ToFloat64 nodes
      - Converts floats to tagged in Phi node inputs
      - Fixes spill double representation
      - Fixes materialisation during a deopt of a double in the stack
      
      Bug: v8:7700
      Change-Id: I9217a64313b4bd5d0015f935c23771ecf9a2c7ca
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610426
      Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80255}
      4837f372
    • Simon Zünd's avatar
      [builtins] Add 'RestartFrameTrampoline' · b0118171
      Simon Zünd authored
      Doc: https://bit.ly/revive-restart-frame
      Context: https://crrev.com/c/3582395 (jumbo CL with the whole feature)
      
      This CL adds a new builtin called "RestartFrameTrampoline". This
      trampoline is relatively simple: It leaves the current frame and
      re-invokes the function. This essentially restarts the function and
      is one of the key components required to bring back the "Restart
      frame" DevTools debugging feature.
      
      The builtin is closely related to the "FrameDropperTrampoline"
      removed in the CL https://crrev.com/c/2854750. The key difference
      is that the "FrameDropperTrampoline" dropped to an "arbitrary"
      frame pointer before restarting the function (arbitrary in the
      sense that it was provided as an argument). This caused issues
      as the feature was implemented in a way that the frame pointer
      wasn't necessarily valid anymore.
      
      In comparison, the "RestartFrameTrampoline" relies on the V8
      unwinder to drop it in the correct frame first and is then
      invoked via either the CEntry stub or the deoptimizer
      (see design doc for details).
      
      Bug: chromium:1303521
      Change-Id: I7bd46620808f8694c2c776b8bcd267e525d5b581
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3585944
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80254}
      b0118171