1. 23 Jul, 2021 1 commit
  2. 16 Jul, 2021 2 commits
  3. 30 Jun, 2021 1 commit
    • Clemens Backes's avatar
      [cleanup] Remove redundant FLAG_SCOPE macros · d701dde2
      Clemens Backes authored
      FLAG_SCOPE_EXTERNAL can be used outside of the v8::internal namespace,
      while FLAG_SCOPE can not.
      This CL refactors FLAG_SCOPE such that it can be used anywhere, and
      removes the redudant FLAG_SCOPE_EXTERNAL macro.
      Also, UNFLAG_SCOPE_EXTERNAL is removed in favor of FLAG_SCOPE_VAL, as
      the word "flag" in the macro name is meant to refer to a flag, and not
      to the verb or action of "flagging" something, hence "unflag" does not
      match the terminology.
      
      R=ahaas@chromium.org
      
      Bug: v8:11879
      Change-Id: I2d761012c3e4330abb611bf67130eb57ec5bb964
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988920
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75482}
      d701dde2
  4. 24 Jun, 2021 3 commits
  5. 22 Jun, 2021 1 commit
  6. 18 Jun, 2021 1 commit
  7. 07 Jun, 2021 1 commit
  8. 02 Jun, 2021 2 commits
  9. 01 Jun, 2021 1 commit
  10. 31 May, 2021 2 commits
  11. 27 May, 2021 1 commit
  12. 12 May, 2021 1 commit
  13. 10 May, 2021 2 commits
  14. 07 May, 2021 1 commit
    • arthursonzogni's avatar
      (reland) [api] Add API callback setter for the SAB origin trial · 22f124ce
      arthursonzogni authored
      This reland patch:
      https://chromium-review.googlesource.com/c/v8/v8/+/2867473
      (See patchset 1)
      
      The problem was blink injecting interceptor into the window object. It
      observes "observation" and "mutations" on this object. When it happens
      to the initial empty document, the IPC DidAccessInitialDocument() is
      sent and modify the state of the browser process. Causing two tests to
      fail.
      
      The diff (See patchset 1..2) includes:
      1. Use JSObject::HasRealNamedProperty instead of JsObject::HasProperty.
         This skips the interceptor and do not walk the prototype chain.
      2. Invert JSObject::HasRealNamedProperty() with
         IsSharedArrayBufferConstructorEnabled(), just in case. This avoid
         observing the object when not needed.
      
      Original patch description:
      ---
      This change makes it possible to enable SharedArrayBuffer per Context,
      controlling whether it should be enabled or not with a callback. The
      previous implementation of the reverse origin trial for
      SharedArrayBuffer was broken, since the feature could only be enabled
      globally per process, and only if the feature flag is set early enough
      in the v8 initialization. This does not play well with how origin
      trials work.
      
      The implementation is similar to the callbacks that already exist for
      the origin trials for WebAssembly simd and exceptions.
      
      SharedArrayBuffer is still controlled by the flag
      harmony_sharedarraybuffer. If that flag is disabled, then
      SharedArrayBuffer is disabled unconditionally. On top of that, this CL
      introduces a new flag for enabling SharedArrayBuffer per context. If
      that flag is set, a callback is used to determine whether
      SharedArrayBuffer should be enabled.
      
      Note that this only controls whether the SharedArrayBuffer constructor
      should be exposed on the global object or not. It is always possible
      to construct a SharedArrayBuffer using
      
        new WebAssembly.Memory({
          shared:true, initial:0, maximum:0 }).buffer.constructor;
      
      There are few things which I do not like of this approach, but I did
      not have better ideas:
      
      1. The complex logic of dobule flag + callback. However, this seemed
      the best way to me to not break embedders which rely on that flag
      being enabled by default.
      
      2. The fact that what actually matters is just whether the callback
      returns `true` once. It would be good to check that the callback gives
      a consistent return value, or to provide a better API that cannot be
      missunderstood.
      
      Bug: chromium:923807,chromium:1071424,chromium:1138860
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2867473Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Antonio Sartori <antoniosartori@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74378}
      
      ---
      
      Bug: chromium:923807,chromium:1071424,chromium:1138860,chromium:1206187
      Change-Id: Ibc6b4f8c0e0827178b7f0cbe4b942444bbbe6216
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2880215Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarLutz Vahl <vahl@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Auto-Submit: Arthur Sonzogni <arthursonzogni@chromium.org>
      Commit-Queue: Hannes Payer <hpayer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74441}
      22f124ce
  15. 06 May, 2021 1 commit
    • Nico Hartmann's avatar
      Revert "[api] Add API callback setter for the SAB origin trial" · 4ce88f56
      Nico Hartmann authored
      This reverts commit bc1eb7b4.
      
      Reason for revert: https://ci.chromium.org/ui/p/chromium/builders/try/android-pie-arm64-rel/369203/overview
      
      Original change's description:
      > [api] Add API callback setter for the SAB origin trial
      >
      > This change makes it possible to enable SharedArrayBuffer per Context,
      > controlling whether it should be enabled or not with a callback. The
      > previous implementation of the reverse origin trial for
      > SharedArrayBuffer was broken, since the feature could only be enabled
      > globally per process, and only if the feature flag is set early enough
      > in the v8 initialization. This does not play well with how origin
      > trials work.
      >
      > The implementation is similar to the callbacks that already exist for
      > the origin trials for WebAssembly simd and exceptions.
      >
      > SharedArrayBuffer is still controlled by the flag
      > harmony_sharedarraybuffer. If that flag is disabled, then
      > SharedArrayBuffer is disabled unconditionally. On top of that, this CL
      > introduces a new flag for enabling SharedArrayBuffer per context. If
      > that flag is set, a callback is used to determine whether
      > SharedArrayBuffer should be enabled.
      >
      >
      > Note that this only controls whether the SharedArrayBuffer constructor
      > should be exposed on the global object or not. It is always possible
      > to construct a SharedArrayBuffer using
      >
      >   new WebAssembly.Memory({
      >     shared:true, initial:0, maximum:0 }).buffer.constructor;
      >
      >
      > There are few things which I do not like of this approach, but I did
      > not have better ideas:
      >
      > 1. The complex logic of dobule flag + callback. However, this seemed
      > the best way to me to not break embedders which rely on that flag
      > being enabled by default.
      >
      > 2. The fact that what actually matters is just whether the callback
      > returns `true` once. It would be good to check that the callback gives
      > a consistent return value, or to provide a better API that cannot be
      > missunderstood.
      >
      >
      > Bug: chromium:923807,chromium:1071424,chromium:1138860
      > Change-Id: Ibe3776fad4d3bff5dda9066967e4b20328014266
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2867473
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Antonio Sartori <antoniosartori@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#74378}
      
      Bug: chromium:923807
      Bug: chromium:1071424
      Bug: chromium:1138860
      Change-Id: Iec678dee130db891c2096e47bc072a5d77ae9476
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874403
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarLutz Vahl <vahl@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74404}
      4ce88f56
  16. 05 May, 2021 1 commit
    • Antonio Sartori's avatar
      [api] Add API callback setter for the SAB origin trial · bc1eb7b4
      Antonio Sartori authored
      This change makes it possible to enable SharedArrayBuffer per Context,
      controlling whether it should be enabled or not with a callback. The
      previous implementation of the reverse origin trial for
      SharedArrayBuffer was broken, since the feature could only be enabled
      globally per process, and only if the feature flag is set early enough
      in the v8 initialization. This does not play well with how origin
      trials work.
      
      The implementation is similar to the callbacks that already exist for
      the origin trials for WebAssembly simd and exceptions.
      
      SharedArrayBuffer is still controlled by the flag
      harmony_sharedarraybuffer. If that flag is disabled, then
      SharedArrayBuffer is disabled unconditionally. On top of that, this CL
      introduces a new flag for enabling SharedArrayBuffer per context. If
      that flag is set, a callback is used to determine whether
      SharedArrayBuffer should be enabled.
      
      
      Note that this only controls whether the SharedArrayBuffer constructor
      should be exposed on the global object or not. It is always possible
      to construct a SharedArrayBuffer using
      
        new WebAssembly.Memory({
          shared:true, initial:0, maximum:0 }).buffer.constructor;
      
      
      There are few things which I do not like of this approach, but I did
      not have better ideas:
      
      1. The complex logic of dobule flag + callback. However, this seemed
      the best way to me to not break embedders which rely on that flag
      being enabled by default.
      
      2. The fact that what actually matters is just whether the callback
      returns `true` once. It would be good to check that the callback gives
      a consistent return value, or to provide a better API that cannot be
      missunderstood.
      
      
      Bug: chromium:923807,chromium:1071424,chromium:1138860
      Change-Id: Ibe3776fad4d3bff5dda9066967e4b20328014266
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2867473Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Antonio Sartori <antoniosartori@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74378}
      bc1eb7b4
  17. 03 May, 2021 1 commit
  18. 30 Apr, 2021 1 commit
  19. 27 Apr, 2021 1 commit
  20. 26 Apr, 2021 1 commit
  21. 20 Apr, 2021 1 commit
    • Maya Lekova's avatar
      Reland "[fastcall] Add support for leaf interface type checks" · 5540fbfc
      Maya Lekova authored
      This is a reland of 6124a534
      
      It fixes a UAF issue in the d8 test by moving the test API object
      constructor to PerIsolateData. It also fixes a crash in Chromium
      caused by current usage of v8::ApiObject, which should be migrated
      to v8::Value*.
      
      Original change's description:
      > [fastcall] Add support for leaf interface type checks
      >
      > This CL adds an IsTemplateForApiObject method to FunctionTemplate
      > allowing the embedder to check whether a given API object was
      > instantiated by this template without including parent templates
      > in the search. It also replaces the v8::ApiObject in the fast API
      > with a raw v8::Value pointer to allow use of standard C++ casts.
      >
      > Bug: chromium:1052746
      > Change-Id: I0812ec8b4daaa5f5005aabf10b63e1e84e0b8f03
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595310
      > Commit-Queue: Maya Lekova <mslekova@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Sathya Gunasekaran  <gsathya@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73999}
      
      Bug: chromium:1052746, chromium:1199900
      Change-Id: I4b7f0c9e9152919dde4a1d0c48fbf5ac8c5b13d8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2835711Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74064}
      5540fbfc
  22. 16 Apr, 2021 2 commits
  23. 14 Apr, 2021 1 commit
  24. 12 Apr, 2021 1 commit
  25. 25 Mar, 2021 2 commits
  26. 23 Mar, 2021 1 commit
    • Nico Hartmann's avatar
      Reland "[TurboFan] Move FunctionTemplateInfo to never serialized" · 07db5a65
      Nico Hartmann authored
      This reverts commit c85b7a44.
      
      This reland fixes missing serialization of objects stored in
      CallHandlerInfo::data by adding necessary handling of these objects
      in FunctionTemplateInfoRef::SerializeCallCode when running with
      direct heap access.
      
      Drive-by: Remove declaration of CallHandlerInfoRef::Serialize, which
      did not have a definition.
      
      Original change's description:
      > [TurboFan] Move FunctionTemplateInfo to never serialized
      >
      > This CL moves FunctionTemplateInfo to the list of never serialized
      > objects, allowing direct heap reads. To make this threadsafe, the CL:
      > - adds necessary atomic (relaxed/acquire-release) operations to the
      >   accessors of FunctionTemplateInfo.
      > - changes FunctionTemplateInfoRef::LookupHolderOfExpectedType to be
      >   usable from the background thread (e.g. no handle construction) with
      >   the caveat of skipping optimization in some cases where necessary
      >   JSObjects are not serialized.
      >
      > Drive-by: Add missing serialization of objects possibly reachable
      > through CallHandlerInfo::data.
      >
      > Bug: v8:7790
      > Change-Id: I49cf4f328ecfab368dff9076fde8f5783ead3246
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679687
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73364}
      
      Bug: v8:7790, chromium:1188563
      Change-Id: Ib43f1eaf0592d2565292e86dea5acfc41a58f637
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2773807Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73599}
      07db5a65
  27. 15 Mar, 2021 1 commit
  28. 12 Mar, 2021 1 commit
  29. 11 Mar, 2021 3 commits
    • Clemens Backes's avatar
      Reland "[no-wasm] Exclude src/wasm from compilation" · 3f9ff062
      Clemens Backes authored
      This is a reland of 80f5dfda. A condition
      in pipeline.cc was inverted, which lead to a CSA verifier error.
      
      Original change's description:
      > [no-wasm] Exclude src/wasm from compilation
      >
      > This is the biggest chunk, including
      > - all of src/wasm,
      > - torque file for wasm objects,
      > - torque file for wasm builtins,
      > - wasm builtins,
      > - wasm runtime functions,
      > - int64 lowering,
      > - simd scala lowering,
      > - WasmGraphBuilder (TF graph construction for wasm),
      > - wasm frame types,
      > - wasm interrupts,
      > - the JSWasmCall opcode,
      > - wasm backing store allocation.
      >
      > Those components are all recursively entangled, so I found no way to
      > split this change up further.
      >
      > Some includes that were recursively included by wasm headers needed to
      > be added explicitly now.
      >
      > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
      > because it only tests wasm backing stores. This file is excluded from
      > no-wasm builds then.
      >
      > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
      >
      > Bug: v8:11238
      > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73344}
      
      TBR=jgruber@chromium.org
      
      Bug: v8:11238
      Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585
      Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73348}
      3f9ff062
    • Clemens Backes's avatar
      Revert "[no-wasm] Exclude src/wasm from compilation" · 92bc3d38
      Clemens Backes authored
      This reverts commit 80f5dfda.
      
      Reason for revert: Fails CSA verification: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20verify%20csa/21766/overview
      
      Original change's description:
      > [no-wasm] Exclude src/wasm from compilation
      >
      > This is the biggest chunk, including
      > - all of src/wasm,
      > - torque file for wasm objects,
      > - torque file for wasm builtins,
      > - wasm builtins,
      > - wasm runtime functions,
      > - int64 lowering,
      > - simd scala lowering,
      > - WasmGraphBuilder (TF graph construction for wasm),
      > - wasm frame types,
      > - wasm interrupts,
      > - the JSWasmCall opcode,
      > - wasm backing store allocation.
      >
      > Those components are all recursively entangled, so I found no way to
      > split this change up further.
      >
      > Some includes that were recursively included by wasm headers needed to
      > be added explicitly now.
      >
      > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
      > because it only tests wasm backing stores. This file is excluded from
      > no-wasm builds then.
      >
      > R=​jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
      >
      > Bug: v8:11238
      > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73344}
      
      Bug: v8:11238
      Change-Id: I93672002c1faa36bb0bb5b4a9cc2032ee2ccd814
      Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752866
      Auto-Submit: Clemens Backes <clemensb@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/master@{#73346}
      92bc3d38
    • Clemens Backes's avatar
      [no-wasm] Exclude src/wasm from compilation · 80f5dfda
      Clemens Backes authored
      This is the biggest chunk, including
      - all of src/wasm,
      - torque file for wasm objects,
      - torque file for wasm builtins,
      - wasm builtins,
      - wasm runtime functions,
      - int64 lowering,
      - simd scala lowering,
      - WasmGraphBuilder (TF graph construction for wasm),
      - wasm frame types,
      - wasm interrupts,
      - the JSWasmCall opcode,
      - wasm backing store allocation.
      
      Those components are all recursively entangled, so I found no way to
      split this change up further.
      
      Some includes that were recursively included by wasm headers needed to
      be added explicitly now.
      
      backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
      because it only tests wasm backing stores. This file is excluded from
      no-wasm builds then.
      
      R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
      
      Bug: v8:11238
      Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
      Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73344}
      80f5dfda
  30. 09 Mar, 2021 1 commit