This CL adds support in TurboFan for passing JSArrays as arguments to
fast API callbacks. It also extends the v8::Array class with a
CopyAndConvertArrayToCppBuffer method to allow the embedder to perform
quick conversions of their JSArrays to a C++ buffer. The CL also adds
tests in d8. Design doc:
https://docs.google.com/document/d/1BNKKZNgrGYafx8kqSfNEQqQYY5n4A6mGufss_Vz-h-4/edit#heading=h.c0kgf82jnlpp
Bug: chromium:1052746, chromium:715122
Change-Id: If47ac60d9ebe6462bbf3adff002e2da8e14e8fc8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940900
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75333}
When checks are enabled, ensure that the global handle zap value never
leaks into user code as it indicates that the garbage collector failed
to keep alive an object.
Bug: chromium:1056170
Change-Id: I4836fe49cd6e443d689068af10276ed99b46eb10
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972729
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75330}
Constructors define instance types for their instances while accessors
define a range of permissable instance types for receiver checks.\
Bug: v8:11476
Change-Id: I48b5326ec0a4e847283c2fa5c8f1705302727453
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2821430
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75131}
This CL adds a new method intended for tests or lab settings to
cleanup V8 caches. The synchronous nature of the method greatly reduces
flakiness of blink leak detection in many cases.
Bug: chromium:1217831
Change-Id: I107eddc8b88d91aa7e69430ecfc135fe39538a5c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2948666
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75041}
This commit adds a TryGetCurrent() method to the v8::Isolate class.
The motivation for adding this method this is that in Node.js we've run
into situations where we need to check if there is a current
Isolate and we are using GetCurrent() for this. The issue is that for a
debug build of Node.js, the debug check in GetCurrent() will cause a
failure.
The suggestion in this changeset is to allow getting the current
Isolate, or null if one does not exist, without any checks.
Change-Id: I01676e4bcdbe86da0496f5df1982d14eb1c9ebf8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2910630
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75004}
They have been disabled for some time and are superseeded by lazy
feedback vector allocation.
Change-Id: Iafc3989b0c1f866ce7d6295d9b13ccaa5ef1c115
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905609
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74711}
In order to support Fast API calls with overloads, store a FixedArray
of c-function addresses and a FixedArray of the corresponding
FunctionInfo*. For now keep using only the first function in the array.
Bug: v8:11739
Change-Id: If23381aa9d04c5cd830043951da9c53836a36328
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876592
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#74643}
The method changes a global flag, depending upon which v8 attaches or
not the SharedArrayBuffer constructor to global objects. Chrome ended
up calling it when some contexts had already been created, leading to
inconsistencies. (Also) because of that, we decided to change the
mechanism for enabling cross-origin isolation (cf.
https://crrev.com/c/2880215). I believe it is better not to expose
this method.
Bug: chromium:923807
Change-Id: I269cb1c5406f999a395bbb7657574c0f73b4ae99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2900224
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Antonio Sartori <antoniosartori@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74600}
As a first step to support Fast API calls with overloads, adds a
new FunctionTemplate constructor that accepts a vector of CFunction*.
Bug: v8:11739
Change-Id: I112b1746768f52df52c893a4f1fb799b6bd90856
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2860838
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#74481}
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/+/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,chromium:1071424,chromium:1138860,chromium:1206187
Change-Id: Ibc6b4f8c0e0827178b7f0cbe4b942444bbbe6216
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2880215
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Lutz Vahl <vahl@chromium.org>
Reviewed-by: Hannes 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}
This reverts commit bc1eb7b478.
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: Lutz Vahl <vahl@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74404}
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}
cpplint rules change over time, and we change the exact rules we enable
for v8. This CL removes NOLINT annotations which are not needed
according to the currently enabled rules.
R=mlippautz@chromium.org
Bug: v8:11717
Change-Id: I41c4c18dd3f70ec255e9d2769ffd25a38f6f2784
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2862764
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74307}
This CL factors out a CodeRange class out of MemoryAllocator.
When V8_COMPRESS_POINTERS_IN_SHARED_CAGE is defined, there is a single
CodeRange shared by all Isolates in the process. This also turns short
builtins back for both configurations of pointer compression. When
sharing a cage, there is a single copy of the re-embedded builtins.
Since a shared pointer cage is still experimental, to avoid API churn
this CodeRange's size is not configurable and is always the maximal size
depending on the underlying platform.
Change-Id: Ie94f52746f2c5450247a999cc6071e3914d4cf0c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2819206
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74261}
With top-level await enabled by default, the behavior of
v8::Module::Evaluate is changed to always return a Promise, and should
be documented.
No-try: true
Change-Id: I8bf41a18d8d98befecd62d6423ab37fdbaac3aad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2854874
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74238}
This CL makes the object passed as argument to IsLeafTemplateForApiObject
be received as a handle instead of a raw C++ pointer. From the codegen
point of view, the memory representation is the same, so this doesn't
change its semantics.
Bug: chromium:1052746
Change-Id: Ibc116aa4d577ba95f30d1014f15f34ef3fbb1a35
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2851884
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74220}
Untangles the non-tracing GC optimization (Scavenger) that allows for
dropping objects that are only reachable from certain API references
from EmbedderHeapTracer. Instead, allow setting it on Isolate.
This allows for using the optimization when using cppgc.
Chromium-side: https://crrev.com/c/2844587
Bug: chromium:1056170
Change-Id: I20f28dd84c808872c7f9559c8c168e828794dd1d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2844657
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74135}
As we can still intend to run the web-exposed profiler outside of an
origin-isolated environment, add support back for filtering by
v8::Context.
This reverts commit 05af368100.
Bug: chromium:956688
Change-Id: Idd98bea3213b5963f689a04de6c3743073efc587
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2785806
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Andrew Comminos <acomminos@fb.com>
Cr-Commit-Position: refs/heads/master@{#74112}
This is a reland of d5457f5fb7
after a speculative revert.
Additionally it fixes an issue with throwing promise hooks.
Original change's description:
> [api] JSFunction PromiseHook for v8::Context
>
> This will enable Node.js to get much better performance from async_hooks
> as currently PromiseHook delegates to C++ for the hook function and then
> Node.js delegates it right back to JavaScript, introducing several
> unnecessary barrier hops in code that gets called very, very frequently
> in modern, promise-heavy applications.
>
> This API mirrors the form of the original C++ function based PromiseHook
> API, however it is intentionally separate to allow it to use JSFunctions
> triggered within generated code to, as much as possible, avoid entering
> runtime functions entirely.
>
> Because PromiseHook has internal use also, beyond just the Node.js use,
> I have opted to leave the existing API intact and keep this separate to
> avoid conflicting with any possible behaviour expectations of other API
> users.
>
> The design ideas for this new API stemmed from discussion with some V8
> team members at a previous Node.js Diagnostics Summit hosted by Google
> in Munich, and the relevant documentation of the discussion can be found
> here: https://docs.google.com/document/d/1g8OrG5lMIUhRn1zbkutgY83MiTSMx-0NHDs8Bf-nXxM/edit#heading=h.w1bavzz80l1e
>
> A summary of the reasons for why this new design is important can be
> found here: https://docs.google.com/document/d/1vtgoT4_kjgOr-Bl605HR2T6_SC-C8uWzYaOPDK5pmRo/edit?usp=sharing
>
> Bug: v8:11025
> Change-Id: I0b403b00c37d3020b5af07b654b860659d3a7697
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2759188
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73858}
Bug: v8:11025
Bug: chromium:1197475
Change-Id: I73a71e97d9c3dff89a2b092c3fe4adff81ede8ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2823917
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74071}
This is a reland of 6124a534b2
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/+/2835711
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74064}
This is a reland of c83c9590ba
Changes since revert: nothing, issue was crbug.com/v8/11666
Original change's description:
> [ic] Add a new MegaDOM IC
>
> This patch implements the MegaDOM IC setup and access. A new MegaDOM
> IC state indicates that we've seen only DOM accessors at this access
> site.
>
> This CL only adds support for DOM getters in LoadIC, other kinds of
> access will be added in follow on CLs.
>
> Still remaining TODO before shipping:
> 1. Have a mechanism to invalidate the protector
> 2. Have a mechanism to find the accessors that aren't overloaded
> 3. Use a new builtin to miss to runtime on access check failure
>
> Change-Id: Ie12efe5e9fa284f023043b996d61e7d74e710ee2
> Bug: v8:11321
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618239
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Dan Elphick <delphick@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73733}
Bug: v8:11321
Change-Id: I2bec54465542b5b40c42adb6eb12b6ce72cce5bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2794439
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74056}
This reverts commit 6124a534b2.
Reason for revert: On suspicion of blocking V8 roll: https://ci.chromium.org/ui/p/chromium/builders/try/win10_chromium_x64_rel_ng/839568/overview
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
Change-Id: Ic99ec616310f0f75800c3dad393b5d2d685b76ab
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2829988
Auto-Submit: Shu-yu Guo <syg@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@{#74016}
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}
The method was scheduled for removal in M92, as finaly part of the
fn.displayName support removal.
Fixed: chromium:1177685
Doc: https://bit.ly/devtools-function-displayName-removal
Change-Id: I243dd6c9849a6f39e76dd003300b639bfd8df604
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2821954
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73930}
With a shared cage, there's no easy way to recover an Isolate from a
heap pointer. Symbol::Description relies on RO symbols' description slot
being uncompressed so a Handle could point to it. This isn't possible
with a shared cage without going through TLS to get an Isolate for
Handle construction, so deprecate the method in favor of one that takes
an Isolate directly.
Bug: v8:11460
Change-Id: I69b2b7d77f4c00d0f58954cd80e22cba5ff222e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2802860
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73924}
This reverts commit d5457f5fb7.
Reason for revert:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/32999
Original change's description:
> [api] JSFunction PromiseHook for v8::Context
>
> This will enable Node.js to get much better performance from async_hooks
> as currently PromiseHook delegates to C++ for the hook function and then
> Node.js delegates it right back to JavaScript, introducing several
> unnecessary barrier hops in code that gets called very, very frequently
> in modern, promise-heavy applications.
>
> This API mirrors the form of the original C++ function based PromiseHook
> API, however it is intentionally separate to allow it to use JSFunctions
> triggered within generated code to, as much as possible, avoid entering
> runtime functions entirely.
>
> Because PromiseHook has internal use also, beyond just the Node.js use,
> I have opted to leave the existing API intact and keep this separate to
> avoid conflicting with any possible behaviour expectations of other API
> users.
>
> The design ideas for this new API stemmed from discussion with some V8
> team members at a previous Node.js Diagnostics Summit hosted by Google
> in Munich, and the relevant documentation of the discussion can be found
> here: https://docs.google.com/document/d/1g8OrG5lMIUhRn1zbkutgY83MiTSMx-0NHDs8Bf-nXxM/edit#heading=h.w1bavzz80l1e
>
> A summary of the reasons for why this new design is important can be
> found here: https://docs.google.com/document/d/1vtgoT4_kjgOr-Bl605HR2T6_SC-C8uWzYaOPDK5pmRo/edit?usp=sharing
>
> Bug: v8:11025
> Change-Id: I0b403b00c37d3020b5af07b654b860659d3a7697
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2759188
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73858}
Bug: v8:11025
Change-Id: Ie7345c4505f39c973f9f0dbca745b591cff63f3f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814740
Auto-Submit: Michael Achenbach <machenbach@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@{#73862}
This will enable Node.js to get much better performance from async_hooks
as currently PromiseHook delegates to C++ for the hook function and then
Node.js delegates it right back to JavaScript, introducing several
unnecessary barrier hops in code that gets called very, very frequently
in modern, promise-heavy applications.
This API mirrors the form of the original C++ function based PromiseHook
API, however it is intentionally separate to allow it to use JSFunctions
triggered within generated code to, as much as possible, avoid entering
runtime functions entirely.
Because PromiseHook has internal use also, beyond just the Node.js use,
I have opted to leave the existing API intact and keep this separate to
avoid conflicting with any possible behaviour expectations of other API
users.
The design ideas for this new API stemmed from discussion with some V8
team members at a previous Node.js Diagnostics Summit hosted by Google
in Munich, and the relevant documentation of the discussion can be found
here: https://docs.google.com/document/d/1g8OrG5lMIUhRn1zbkutgY83MiTSMx-0NHDs8Bf-nXxM/edit#heading=h.w1bavzz80l1e
A summary of the reasons for why this new design is important can be
found here: https://docs.google.com/document/d/1vtgoT4_kjgOr-Bl605HR2T6_SC-C8uWzYaOPDK5pmRo/edit?usp=sharing
Bug: v8:11025
Change-Id: I0b403b00c37d3020b5af07b654b860659d3a7697
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2759188
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73858}
This reverts commit c83c9590ba.
Reason for revert: Speculatively reverting for a failure on Arm GC stress bot - https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Arm%20GC%20Stress/b8851256837192083520/overview
Original change's description:
> [ic] Add a new MegaDOM IC
>
> This patch implements the MegaDOM IC setup and access. A new MegaDOM
> IC state indicates that we've seen only DOM accessors at this access
> site.
>
> This CL only adds support for DOM getters in LoadIC, other kinds of
> access will be added in follow on CLs.
>
> Still remaining TODO before shipping:
> 1. Have a mechanism to invalidate the protector
> 2. Have a mechanism to find the accessors that aren't overloaded
> 3. Use a new builtin to miss to runtime on access check failure
>
> Change-Id: Ie12efe5e9fa284f023043b996d61e7d74e710ee2
> Bug: v8:11321
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618239
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Dan Elphick <delphick@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73733}
Bug: v8:11321
Change-Id: Ib6a55796f2a3c345d4923f9eaa215a6ff55ed15b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2794437
Auto-Submit: 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/master@{#73734}
This patch implements the MegaDOM IC setup and access. A new MegaDOM
IC state indicates that we've seen only DOM accessors at this access
site.
This CL only adds support for DOM getters in LoadIC, other kinds of
access will be added in follow on CLs.
Still remaining TODO before shipping:
1. Have a mechanism to invalidate the protector
2. Have a mechanism to find the accessors that aren't overloaded
3. Use a new builtin to miss to runtime on access check failure
Change-Id: Ie12efe5e9fa284f023043b996d61e7d74e710ee2
Bug: v8:11321
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618239
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73733}
Origin trials allow webpages to use experimental features even though
the features are not yet enabled by default. These features will then
get enabled per execution context: it is possible that the feature is
enabled in one execution context but disabled in another execution
context. In V8 we check for origin trials by calling a callback provided
by the embedder that takes the context as a parameter and returns
whether a feature is enabled in this context or not.
This approach fails when a feature changes the context itself, e.g. by
extending the global object. In that case the context is not available
yet to check for the origin trial.
To solve the problem this CL adds a new API function that can be called
by the embedder to notify V8 that context with the origin trial
information is finished. After that V8 can read the origin trial
information from the context and extend e.g. the global object with the
origin trial features.
Additionally to the API this CL also adds code to enable the
WebAssembly.Exception constructor conditionally, depending on whether
it has been enabled by an origin trial or not.
The Blink-side change: https://crrev.com/c/2775573R=ulan@chromium.org, jkummerow@chromium.org
Change-Id: Ic05c4a89eb3e0e31469e49da8767d630c43b2e00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2773287
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73597}
Add a V8 API to update load start time for RAIL PERFORMANCE_LOAD mode
Bug: v8:10947
Change-Id: If86a815f8974b47a6f4ba82c3661c21b73f39553
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423403
Auto-Submit: Hong Zheng <hong.zheng@intel.com>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73393}
Handles are notorious for preventing compiler optimizations. We should
avoid them for simple const functions.
- Mark more API functions const
- Mark more String functions const
Bug: v8:11195, chromium:808503, v8:11263
Change-Id: I9940e85600bc7d19027039d807b3313e2dcccdc7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2575065
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73159}
These simplify production of extra information in stack traces or
dereferencing source maps in processing stack traces. While these
can be managed externally, this can be very complicated in
environments where scripts come from many different sources,
possibly not even under embedder control. Since V8 already has
easy access to this information, it's nice to share it with
embedders.
Bug: v8:11509
Change-Id: Ic5a1685adf4cdf456bdf7191ce815f728cf491e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2724571
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73148}
After deprecation and removal of the old misleading API we re-add
v8::String::IsExternal which returns true for both, external one-byte and
external two-byte strings.
Bug: v8:10641
Change-Id: I4c66d4df891f7180c7a727a45c1fbd254a7f5c02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2726512
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73137}
Add a Utf16CharacterStream for windows-1252, which uses a table to
covert from windows-1252 to the appropriate uc16 character. This fixes
issues where windows-1252 encoded source was treated like latin-1.
This introduces a new encoding type in the API, so embedders will have
to opt-in to using this new stream.
Fixed: v8:9315
Change-Id: I2e847c2d4f1727281f6be24b4743d77bb232a62d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2729338
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73134}
This is a reland of ed225df70c
Reland changes: removed #if DEBUG from v8.h since it had compile errors
in chromium + windows. Also wasn't needed anyway since the method it was
calling was just a DCHECK.
Original change's description:
> [objects] Cache the ExternalString's data in its resource
>
> For external uncached strings (also called "Small External Strings")
> with cacheable resources, we can cache its resource's data at the
> string's creation time. This allows us to safely read the data from the
> background as we wouldn't trigger a data() callback.
>
> For more information regarding the investigation and possible proposals
> see
> https://docs.google.com/document/d/101eAQqFpBPWFGNJicxtdlwYShJkTOUsEuxkVVeu5Hrk/edit?usp=sharing
>
> Bug: v8:7790, v8:11463
> Change-Id: I6164092b01a6ccb525a9516f476e066b35fb1f96
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685177
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72862}
Bug: v8:7790
Bug: v8:11463
Change-Id: I7c8a54c814b92c8632fb0bcf5a33f57fec159443
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2710440
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72956}
This reverts commit ed225df70c.
Reason for revert: Blocks the roll, causing compile failures in Chromium:
https://ci.chromium.org/p/chromium/builders/try/win_chromium_compile_dbg_ng/800868?
Original change's description:
> [objects] Cache the ExternalString's data in its resource
>
> For external uncached strings (also called "Small External Strings")
> with cacheable resources, we can cache its resource's data at the
> string's creation time. This allows us to safely read the data from the
> background as we wouldn't trigger a data() callback.
>
> For more information regarding the investigation and possible proposals
> see
> https://docs.google.com/document/d/101eAQqFpBPWFGNJicxtdlwYShJkTOUsEuxkVVeu5Hrk/edit?usp=sharing
>
> Bug: v8:7790, v8:11463
> Change-Id: I6164092b01a6ccb525a9516f476e066b35fb1f96
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685177
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72862}
Bug: v8:7790
Bug: v8:11463
Change-Id: I1d14c2f9872d156d43d5d95c8a032a37ba9379cb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2708824
Auto-Submit: Bill Budge <bbudge@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72880}
For external uncached strings (also called "Small External Strings")
with cacheable resources, we can cache its resource's data at the
string's creation time. This allows us to safely read the data from the
background as we wouldn't trigger a data() callback.
For more information regarding the investigation and possible proposals
see
https://docs.google.com/document/d/101eAQqFpBPWFGNJicxtdlwYShJkTOUsEuxkVVeu5Hrk/edit?usp=sharing
Bug: v8:7790, v8:11463
Change-Id: I6164092b01a6ccb525a9516f476e066b35fb1f96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685177
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72862}
The current API returns a Handle<NativeContext> which can be
optionally null and all the users of this API never actually
checked for this null value.
Previously, this wasn't a problem as all the possible JSObjects
that were user visible would return a valid NativeContext but now
there are wasm objects that don't have a valid constructor so don't
have a NativeContext.
Bug: v8:11451, chromium:1166077
Change-Id: I4fd5edf8f1a750e6f0abb931fd41358e5ae4dfcf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692695
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72769}
The origin trial for WebAssembly Threads is over for quite some time,
WebAssembly Threads are enabled by default. The API can therefore be
removed now.
Bug: v8:11384
Change-Id: I3dd65ff63c1ed31d39a76e5aea08b950ef420f54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690598
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72766}
