1. 31 Jan, 2022 1 commit
  2. 27 Jan, 2022 1 commit
  3. 20 Jan, 2022 1 commit
  4. 17 Jan, 2022 1 commit
  5. 11 Jan, 2022 2 commits
  6. 10 Jan, 2022 3 commits
  7. 15 Dec, 2021 1 commit
    • Samuel Groß's avatar
      V8 Sandbox rebranding · 277fdd1d
      Samuel Groß authored
      This CL renames a number of things related to the V8 sandbox.
      Mainly, what used to be under V8_HEAP_SANDBOX is now under
      V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage
      is now simply the V8 Sandbox:
      
      V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX
      V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS
      V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS
      V8VirtualMemoryCage => Sandbox
      CagedPointer => SandboxedPointer
      fake cage => partially reserved sandbox
      src/security => src/sandbox
      
      This naming scheme should simplify things: the sandbox is now the large
      region of virtual address space inside which V8 mainly operates and
      which should be considered untrusted. Mechanisms like sandboxed pointers
      are then used to attempt to prevent escapes from the sandbox (i.e.
      corruption of memory outside of it). Furthermore, the new naming scheme
      avoids the confusion with the various other "cages" in V8, in
      particular, the VirtualMemoryCage class, by dropping that name entirely.
      
      Future sandbox features are developed under their own V8_SANDBOX_X flag,
      and will, once final, be merged into V8_SANDBOX. Current future features
      are sandboxed external pointers (using the external pointer table), and
      sandboxed pointers (pointers guaranteed to point into the sandbox, e.g.
      because they are encoded as offsets). This CL then also introduces a new
      build flag, v8_enable_sandbox_future, which enables all future features.
      
      Bug: v8:10391
      Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96
      Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322981Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78384}
      277fdd1d
  8. 06 Dec, 2021 1 commit
  9. 02 Dec, 2021 1 commit
  10. 01 Dec, 2021 1 commit
    • Leszek Swirski's avatar
      [compiler-dispatcher] Enqueue tasks for non-eager inner funcs · 5ab1ec1e
      Leszek Swirski authored
      Add suppose for compiling non-eager, non-top-level inner functions in
      parallel, using the compiler dispatcher. This behaviour can be enabled
      with --parallel-compile-tasks-for-lazy.
      
      There are a couple of consequences:
      
        * To support this we need support for off-thread ScopeInfo
          deserialization, so this adds that too.
        * The previous --parallel-compile-tasks flag is renamed to the more
          descriptive --parallel-compile-tasks-for-eager-toplevel.
        * Both parallel-compile-tasks flags are moved onto
          UnoptimizedCompileFlags so that they can be enabled/disabled on a
          per-compile basis (e.g. enabled for streaming, disabled for
          re-parsing).
        * asm.js compilations can now happen without an active Context (in
          the compiler dispatcher's idle finalization) so we can't get a
          ContextId for metric reporting; we'd need to somehow fix this if we
          wanted asm.js UKM but for now it's probably fine.
        * Took the opportunity to clean up some of the "can preparse" logic in
          the parser.
      
      Change-Id: I20b1ec6a6bacfe268808edc8d812b92370c5840d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3281924
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarEmanuel Ziegler <ecmziegler@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78183}
      5ab1ec1e
  11. 30 Nov, 2021 2 commits
  12. 26 Nov, 2021 3 commits
  13. 05 Nov, 2021 1 commit
  14. 28 Oct, 2021 1 commit
    • Tobias Tebbi's avatar
      Reland "[turbofan] extend type asserts to cover all JS types" · 392078fb
      Tobias Tebbi authored
      This is a reland of 45227ffd
      Differences:
      - Handle one more flags conflict in variants.py.
      - Disallow %VerifyType without --concurrent-recompilation.
      
      Original change's description:
      > [turbofan] extend type asserts to cover all JS types
      >
      > Extend type assertions to all types covering JavaScript values.
      > This is achieved by allocating type representations on the heap using
      > newly defined HeapObject subclasses. To allocate these in the compiler,
      > we disable concurrent compilation for the --assert-types flag for now.
      >
      > Fix two type errors that came up with the existing tests:
      > 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
      >    OtherObject.
      > 2. OperationTyper::NumberToString(Type) can type the result as the
      >    HeapConstant Factory::zero_string(). However, NumberToString does
      >    not always produce this string. To avoid regressions, the CL keeps
      >    the HeapConstant type and changes the runtime and builtin code to
      >    always produce the canonical "0" string.
      >
      > A few tests were failing because they check for truncations to work
      > and prevent deoptimization. However, AssertType nodes destroy all
      > truncations (which is by design), so these tests are incompatible
      > and now disabled for the assert_types variant.
      >
      > Drive-by fix: a few minor Torque issues that came up.
      >
      > Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Omer Katz <omerkatz@chromium.org>
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#77565}
      
      Change-Id: I5b3c6745c6ad349ff8c2b199d9afdf0a9b5a7392
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247035
      Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77596}
      392078fb
  15. 27 Oct, 2021 2 commits
    • Maya Lekova's avatar
      Revert "[turbofan] extend type asserts to cover all JS types" · 54f90462
      Maya Lekova authored
      This reverts commit 45227ffd.
      
      Reason for revert: Breaks on gc_stress mode, see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/35988/overview
      
      Original change's description:
      > [turbofan] extend type asserts to cover all JS types
      >
      > Extend type assertions to all types covering JavaScript values.
      > This is achieved by allocating type representations on the heap using
      > newly defined HeapObject subclasses. To allocate these in the compiler,
      > we disable concurrent compilation for the --assert-types flag for now.
      >
      > Fix two type errors that came up with the existing tests:
      > 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
      >    OtherObject.
      > 2. OperationTyper::NumberToString(Type) can type the result as the
      >    HeapConstant Factory::zero_string(). However, NumberToString does
      >    not always produce this string. To avoid regressions, the CL keeps
      >    the HeapConstant type and changes the runtime and builtin code to
      >    always produce the canonical "0" string.
      >
      > A few tests were failing because they check for truncations to work
      > and prevent deoptimization. However, AssertType nodes destroy all
      > truncations (which is by design), so these tests are incompatible
      > and now disabled for the assert_types variant.
      >
      > Drive-by fix: a few minor Torque issues that came up.
      >
      > Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Omer Katz <omerkatz@chromium.org>
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#77565}
      
      Change-Id: Ia779a11fc811846194c7a8d1e40b372b265e7ea4
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247034
      Auto-Submit: Maya Lekova <mslekova@chromium.org>
      Owners-Override: Maya Lekova <mslekova@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/main@{#77566}
      54f90462
    • Tobias Tebbi's avatar
      [turbofan] extend type asserts to cover all JS types · 45227ffd
      Tobias Tebbi authored
      Extend type assertions to all types covering JavaScript values.
      This is achieved by allocating type representations on the heap using
      newly defined HeapObject subclasses. To allocate these in the compiler,
      we disable concurrent compilation for the --assert-types flag for now.
      
      Fix two type errors that came up with the existing tests:
      1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
         OtherObject.
      2. OperationTyper::NumberToString(Type) can type the result as the
         HeapConstant Factory::zero_string(). However, NumberToString does
         not always produce this string. To avoid regressions, the CL keeps
         the HeapConstant type and changes the runtime and builtin code to
         always produce the canonical "0" string.
      
      A few tests were failing because they check for truncations to work
      and prevent deoptimization. However, AssertType nodes destroy all
      truncations (which is by design), so these tests are incompatible
      and now disabled for the assert_types variant.
      
      Drive-by fix: a few minor Torque issues that came up.
      
      Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77565}
      45227ffd
  16. 26 Oct, 2021 1 commit
  17. 21 Oct, 2021 1 commit
  18. 19 Oct, 2021 2 commits
  19. 06 Oct, 2021 1 commit
  20. 01 Oct, 2021 1 commit
  21. 30 Sep, 2021 2 commits
  22. 29 Sep, 2021 1 commit
  23. 08 Sep, 2021 1 commit
  24. 07 Sep, 2021 1 commit
  25. 06 Sep, 2021 1 commit
  26. 03 Sep, 2021 1 commit
  27. 27 Aug, 2021 1 commit
  28. 26 Aug, 2021 1 commit
  29. 25 Aug, 2021 3 commits