1. 17 May, 2022 1 commit
    • Marja Hölttä's avatar
      Reland "[rab/gsab] Temporarily stage --harmony-rab-gsab to enable fuzzing" · df73fd60
      Marja Hölttä authored
      This reverts commit 24286b8e.
      
      Reason for revert: Re-staging the experimental flag for fuzzing
      
      Original change's description:
      > Revert "[rab/gsab] Temporarily stage --harmony-rab-gsab to enable fuzzing"
      >
      > This reverts commit b8f88be0.
      >
      > Reason: disabling an experimental feature in release branch
      >
      > Bug: v8:11111,v8:12870
      > Change-Id: I6fbd6bdb318c0d25e69c04db208a0d5f2b9ebbd7
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3647357
      > Auto-Submit: Marja Hölttä <marja@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#80520}
      
      Bug: v8:11111,v8:12870
      Change-Id: I0a45ed5ce53010196949dda23773d152aa605846
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3647836
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/main@{#80576}
      df73fd60
  2. 13 May, 2022 3 commits
  3. 10 May, 2022 1 commit
  4. 09 May, 2022 1 commit
    • Camillo Bruni's avatar
      [flags] Introduce --max-opt · 40136c1b
      Camillo Bruni authored
      There are currently several flags to tune V8's optimisation level:
        --sparkplug, --maglev, --opt
      
      This CL tries to make this simpler by introducing yet another flag.
      --max-opt limits the maximum optimisation tier and avoids the common
      error to mistake --no-opt with no dynamic optimisations.
      
      Settings:
        --max-opt=999 Allow all optimisations, default configuration.
                      Any number > 3 will do, as long as no other tier will be
                      added.
        --max-opt=0   Allow only ignition
        --max-opt=1   Allow up to sparkplug
        --max-opt=2   Allow up to maglev
        --max-opt=3   Allow up to turbofan
      
      Bug: v8:12825
      Change-Id: Iff9a0fcccdf05e9770168053a1430303613a7299
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605816
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarJakob Linke <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80418}
      40136c1b
  5. 05 May, 2022 1 commit
  6. 04 May, 2022 1 commit
  7. 03 May, 2022 2 commits
  8. 29 Apr, 2022 1 commit
    • Anton Bikineev's avatar
      cppgc: young-gen: Add runtime option for young generation · c7dfa3fa
      Anton Bikineev authored
      The CL introduces a new option --cppgc-young-generation. This option
      can't be enabled statically, because V8 options are parsed after heap
      initialization. The CL changes minor GC so that it can be enabled
      dynamically. The way it works is as follows:
      - the user calls YoungGenerationEnabler::Enable();
      - a heap checks in the next atomic pause whether the flag was enabled;
      - if so, the heap enables young generation for itself.
      
      To avoid barrier regressions without young-generation enabled, the CL changes the meaning of the global flag is-any-incremental-or-concurrent-marking to is-barrier-enabled.
      
      The runtime option would enable us to test young generation on try-
      and performance-bots.
      
      Bug: chromium:1029379
      Change-Id: I664cccdcd208225ffcbf9901f1284b56d088c5c3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3607993
      Commit-Queue: Anton Bikineev <bikineev@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80274}
      c7dfa3fa
  9. 28 Apr, 2022 5 commits
    • 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
    • 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
      [baseline] Create flag to use UserBlocking threads for CSP · a6b8d064
      Victor Gomes authored
      Since Sparkplug compiles pretty quickly and it might impact loading
      time, there is an argument that we should actually use high priority
      threads for CSP.
      
      This adds a flag so that we create a finch experiment to test this
      hypothesis.
      
      Change-Id: Ib8965fbea015ddaeb25503bd92873bfff5daa1ce
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605245
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Auto-Submit: Victor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80251}
      a6b8d064
    • Marja Hölttä's avatar
      [rab/gsab] Temporarily stage --harmony-rab-gsab to enable fuzzing · b8f88be0
      Marja Hölttä authored
      Please revert this commit if anything breaks!
      
      Bug: v8:11111
      Change-Id: Ieaf8a57846df011abc245109c22a5cabe627a087
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610430Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80247}
      b8f88be0
  10. 27 Apr, 2022 3 commits
    • Adam Klein's avatar
      Revert "[rwx][mac] Support fast W^X permission switching on Apple Silicon (M1)" · 10807c9f
      Adam Klein authored
      This reverts commit 9d31f866.
      
      Reason for revert: crashes on Mac/arm64 bots:
      https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20debug/5923/overview
      
      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: Ic07948e036db36326d464a2a901d052aa060a406
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3611665
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Auto-Submit: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80239}
      10807c9f
    • Igor Sheludko's avatar
      [rwx][mac] Support fast W^X permission switching on Apple Silicon (M1) · 9d31f866
      Igor Sheludko authored
      ... 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/+/3579303Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80238}
      9d31f866
    • Patrick Thier's avatar
      [string] Add flag to use string forwarding table instead of ThinString · e6d2edd7
      Patrick Thier authored
      Add flag --always-use-string-forwarding-table to always use the
      forwarding table (usually only used for shared strings) instead of
      ThinString migrations initially (during GC strings will be migrated
      to normal ThinStrings). The goal is to get more coverage of this code
      that is designed for shared strings.
      
      Bug: v8:12007
      Change-Id: I7eb2e5ccf0018c4ac349611aebe337d8288de5c8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3536650Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Commit-Queue: Patrick Thier <pthier@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80206}
      e6d2edd7
  11. 26 Apr, 2022 1 commit
  12. 25 Apr, 2022 1 commit
  13. 21 Apr, 2022 1 commit
    • Leszek Swirski's avatar
      [maglev] Start implenting inlining · c0a63243
      Leszek Swirski authored
      Add a --maglev-inlining flag, and add some half-baked support for
      inlining functions when there is call feedback.
      
      When the flag is enabled and there is call feedback, we create a nested
      MaglevGraphBuilder for the current graph, and pause building the graph
      of the outer function. We manually set up its prologue to set up its
      frame with the arguments pass into the call, build the body with the
      nested graph builder. This inner builder knows that it is building an
      inlined function, and all Return bytecodes will instead emit a Jump to a
      single merge block at the end of the function, where execution of the
      outer function can resume.
      
      These inner function basic blocks are wired into the outer graph with
      new JumpToInline and JumpFromInline control nodes. The idea is that
      subsequent passes will know what the inline function is, and will use
      these to manage the function stack (particularly for codegen and
      especially deopts).
      
      Bug: v8:7700
      Change-Id: I4e9b153f8cf4d06c56e7be6365e7a18b86a773c0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3585958
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80077}
      c0a63243
  14. 20 Apr, 2022 3 commits
  15. 18 Apr, 2022 1 commit
  16. 14 Apr, 2022 1 commit
  17. 12 Apr, 2022 1 commit
  18. 11 Apr, 2022 2 commits
  19. 08 Apr, 2022 2 commits
  20. 07 Apr, 2022 2 commits
  21. 06 Apr, 2022 6 commits