Skip to content

V
V8
Switch branch/tag
  1. 12 Oct, 2021 1 commit
  3. 08 Oct, 2021 2 commits
  5. 06 Oct, 2021 2 commits
  7. 27 Sep, 2021 1 commit
  9. 23 Sep, 2021 1 commit
  11. 16 Sep, 2021 2 commits
  13. 13 Sep, 2021 1 commit
  15. 09 Sep, 2021 1 commit
  17. 25 Aug, 2021 1 commit
  19. 24 Aug, 2021 2 commits
  21. 23 Aug, 2021 3 commits
    • Dan Elphick's avatar
      Revert "[include] Split out v8.h" · 44fe02ce
      Dan Elphick authored 
      This reverts commit d1b27019.

Reason for revert: Broke vtune build, tsan build and possibly others

Original change's description:
> [include] Split out v8.h
>
> This moves every single class/function out of include/v8.h into a
> separate header in include/, which v8.h then includes so that
> externally nothing appears to have changed.
>
> Every include of v8.h from inside v8 has been changed to a more
> fine-grained include.
>
> Previously inline functions defined at the bottom of v8.h would call
> private non-inline functions in the V8 class. Since that class is now
> in v8-initialization.h and is rarely included (as that would create
> dependency cycles), this is not possible and so those methods have been
> moved out of the V8 class into the namespace v8::api_internal.
>
> None of the previous files in include/ now #include v8.h, which means
> if embedders were relying on this transitive dependency then it will
> give compile failures.
>
> v8-inspector.h does depend on v8-scripts.h for the time being to ensure
> that Chrome continue to compile but that change will be reverted once
> those transitive #includes in chrome are changed to include it directly.
>
> Full design:
> https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
>
> Bug: v8:11965
> Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76424}

Bug: v8:11965
Change-Id: Id57313ae992e720c8b19abc975cd69729e1344aa
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113627
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76428}
      44fe02ce
    • Dan Elphick's avatar
      [include] Split out v8.h · d1b27019
      Dan Elphick authored 
      This moves every single class/function out of include/v8.h into a
separate header in include/, which v8.h then includes so that
externally nothing appears to have changed.

Every include of v8.h from inside v8 has been changed to a more
fine-grained include.

Previously inline functions defined at the bottom of v8.h would call
private non-inline functions in the V8 class. Since that class is now
in v8-initialization.h and is rarely included (as that would create
dependency cycles), this is not possible and so those methods have been
moved out of the V8 class into the namespace v8::api_internal.

None of the previous files in include/ now #include v8.h, which means
if embedders were relying on this transitive dependency then it will
give compile failures.

v8-inspector.h does depend on v8-scripts.h for the time being to ensure
that Chrome continue to compile but that change will be reverted once
those transitive #includes in chrome are changed to include it directly.

Full design:
https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing

Bug: v8:11965
Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76424}
      d1b27019
    • Camillo Bruni's avatar
      [modules] Handle missing eval origin with dynamic imports · 7b07aa0e
      Camillo Bruni authored 
      Bug: chromium:1237730
Change-Id: Ib604a5d3dc8931f195d6508048937ee735e18fd8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3107306
Auto-Submit: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76421}
      7b07aa0e
  23. 11 Aug, 2021 1 commit
  25. 06 Aug, 2021 1 commit
  27. 05 Aug, 2021 1 commit
  29. 29 Jul, 2021 1 commit
  31. 26 Jul, 2021 1 commit
    • Leszek Swirski's avatar
      Reland "[offthread] Template deserializer on Isolate" · 6f898234
      Leszek Swirski authored 
      This is a reland of e24fa913
It fixes the heap verification errors by going back to using MakeThin
instead of manually creating a filler (that then makes the verifier
think that this was array left-trimming).

Original change's description:
> [offthread] Template deserializer on Isolate
>
> Make the deserializer class templated on Isolate/LocalIsolate. This
> allows the ObjectSerializer to be split into a main-thread and offthread
> variant, with the latter taking a LocalIsolate.
>
> Eventually, we probably want to anyway split off the code-cache de/serializer
> to a separate implementation (for various reasons), and this the only one that
> wants off-thread finalization, and at this point the deserializer can revert
> back to being un-templated, used only for bootstrapping. However, this is the
> simplest way, for now, to enable off-thread deserialization.
>
> Bug: chromium:1075999
> Change-Id: I49c0d2c5409f0aa58183673785296756c3714f22
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2562254
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75834}

Bug: chromium:1075999
Change-Id: I1d81fad2550a2a9f04dd0f9d8e66422d28faf378
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3043960Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75918}
      6f898234
  33. 22 Jul, 2021 1 commit
  35. 21 Jul, 2021 2 commits
    • Nico Hartmann's avatar
      Revert "[offthread] Template deserializer on Isolate" · c73d759b
      Nico Hartmann authored 
      This reverts commit e24fa913.

Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/18917/overview

Original change's description:
> [offthread] Template deserializer on Isolate
>
> Make the deserializer class templated on Isolate/LocalIsolate. This
> allows the ObjectSerializer to be split into a main-thread and offthread
> variant, with the latter taking a LocalIsolate.
>
> Eventually, we probably want to anyway split off the code-cache de/serializer
> to a separate implementation (for various reasons), and this the only one that
> wants off-thread finalization, and at this point the deserializer can revert
> back to being un-templated, used only for bootstrapping. However, this is the
> simplest way, for now, to enable off-thread deserialization.
>
> Bug: chromium:1075999
> Change-Id: I49c0d2c5409f0aa58183673785296756c3714f22
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2562254
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75834}

Bug: chromium:1075999
Change-Id: Id699ebe0c17d3a61ec35b0f78417306175271647
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041675Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75836}
      c73d759b
    • Leszek Swirski's avatar
      [offthread] Template deserializer on Isolate · e24fa913
      Leszek Swirski authored 
      Make the deserializer class templated on Isolate/LocalIsolate. This
allows the ObjectSerializer to be split into a main-thread and offthread
variant, with the latter taking a LocalIsolate.

Eventually, we probably want to anyway split off the code-cache de/serializer
to a separate implementation (for various reasons), and this the only one that
wants off-thread finalization, and at this point the deserializer can revert
back to being un-templated, used only for bootstrapping. However, this is the
simplest way, for now, to enable off-thread deserialization.

Bug: chromium:1075999
Change-Id: I49c0d2c5409f0aa58183673785296756c3714f22
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2562254Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75834}
      e24fa913
  37. 07 Jul, 2021 1 commit
  39. 05 Jul, 2021 1 commit
  41. 28 Jun, 2021 1 commit
  43. 24 Jun, 2021 1 commit
    • Maya Lekova's avatar
      Migrate PerIsolateAssertScope storage to separate booleans · d11ccc5c
      Maya Lekova authored 
      This CL modifies the underlying storage of PerIsolateAssertScope from
a bitfield to separate booleans. This slightly increases the space taken
by the isolate, but allows for easier access to the individual fields,
which is a prerequisite for implementing assertion scopes in TurboFan.

It also refactors the template PerIsolateAssertScope class to separate
simple C++ scope classes, defined through macros.

Bug: chromium:1218898
Change-Id: Ia5e43352ebba28be6f013376b75f13ec8d5dc972
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2975303
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75369}
      d11ccc5c
  45. 21 Jun, 2021 1 commit
  47. 14 Jun, 2021 1 commit
  49. 09 Jun, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] RawFastPropertyAt without serialization · 9bfd401e
      Jakob Gruber authored 
      This is a step towards making JSObjectRef non-serialized.

Change JSObjectRef::RawFastPropertyAt to use a direct load with
relaxed semantics. Special handling of `uninitialized` sentinel values
is moved to the only use-site.

A new lock `boilerplate_migration_access` protects against concurrent
boilerplate migrations while we are iterating over properties.

Bug: v8:7790
Change-Id: Ic9de54ca16c1f3364d497a77058cfa33d48dd4a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928184
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75033}
      9bfd401e
  51. 02 Jun, 2021 1 commit
  53. 19 May, 2021 1 commit
  55. 11 May, 2021 2 commits
  57. 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
  59. 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
  61. 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
  63. 04 May, 2021 1 commit