Introduce OffThreadFactory with initial string construction support.
The OffThreadFactory shares with Factory a new CRTP base class, called
FactoryBase. Methods in FactoryBase return a FactoryHandle<Factory, T>
alias, which is Handle<T> for normal Factory and a new OffThreadHandle<T>
for OffThreadFactory. OffThreadHandle<T> behaves like Handle<T>, except
it stores the object in-line rather than needing external storage.
Any shared factory methods are moved into FactoryBase, which uses CRTP
to call the sub-class's AllocateRaw method (plus a few more customization
points which need Isolate access on the main thread).
Methods that used to take an Isolate or Factory, and are needed off the
main thread, are now expected to be templated on the factory type and
to use the appropriate handle.
Once an OffThreadFactory has finished being used (e.g. off-thread
compilation completed) its pages are "Published" into the main-thread
Heap. To deal with string internalization without creating a bunch of
ThinStrings, this is done in two stages:
1. 'FinishOffThread': The off-thread pages are walked to
collect all slots pointing to "internalized" strings. After this is
called it is invalid to allocate any more objects with the factory.
2. 'Publish': On the main thread, we transform these slots into
<Handle to holder, offset> pairs, then for each saved slot
re-internalize its string and update the slot to point to the
internalized string.
Bug: chromium:1011762
Change-Id: I008a694da3c357de34362bd86fe7e1f46b535d5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1992434
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65787}
There is no particular reason that PropertyDescriptorObject should be a
subclass of FixedArray. By using a separate struct type, we get better
generated accessor functions, automatic verification, and runtime type
info, plus we save four bytes per instance.
Change-Id: If076782832aa9398806794e4ee6d019aea2f92b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1999463
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#65756}
Simulator-specific instructions are very useful, we can:
- Place breakpoints that enable the simulator's interactive debugger, allowing
us to see registers, the stack and print JS objects.
- Enable and disable simulator tracing dynamically.
- Call printf() directly, as the simulator cannot easily support its calling
convention.
However these tools are not available when generating builtins. The reason is
that when cross-compiling, builtins are generated for real hardware but may
still run inside the simulator on the host if we have a custom snapshot. Using
the `v8_embed_script` GN option will do that for example but embedders may also
do this with the V8 API.
mksnapshot cannot tell the difference between generating code for a simulator
build and a cross-build. If we change this, we can allow us to use
simulator-specific features in builtins in simulator builds.
So in this patch we:
- Introduce a --target_is_simulator mksnapshot flag to drive the
enable_simulator_code Assembler option.
- Make sure the assembler respect the option instead of the USE_SIMULATOR
macro.
Change-Id: I7a7249f514427c1a2518a1af3679679596a72c7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1991497
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#65734}
This CL adds the ArrayBufferExtension class, which is used to track
JSArrayBuffers in a linked list. The ArrayBufferExtension is going to
replace the ArrayBufferTracker in the future but is currently behind
the v8_enable_array_buffer_extension feature flag.
When enabled, each JSArrayBuffer has a corresponding native-heap
allocated ArrayBufferExtension object. All extensions are currently
tracked in a single linked list. During marking the GC not only
marks the JSArrayBuffer but also its extension object. At the end of
mark-compact the GC iterates all extensions and removes unmarked ones.
Change-Id: I88298be255944d5ae1327c91b0d7f0fdbcd486d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969791
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65724}
This changes the marking worklist draining for the main thread
marker and the concurrent marker to use the following algorithm in
per-context mode:
1) Pop an object from the marking worklist.
2) Try to infer the native context that owns the objects.
This is done using a new NativeContextInferrer class.
3) If the inference is successful, then change the active marking
worklist to the worklist of the inferred native context.
4) Otherwise, keep the current active marking worklist.
5) Visit the object. Newly discovered objects will be pushed
onto the active marking worklist.
6) Account the object size for the native context corresponding
to the active marking worklist.
This is done using a new NativeContextStats class.
The main property of the algorithm is that each object for which
we couldn't infer the native context is either attributed to
the native context retaining it or is not attributed to any native
context.
Bug: chromium:973627
Change-Id: Ide4ab992275d115279f971d89ace657f4c05e176
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1981491
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65663}
In the process:
* Rework the Torque definition of ScopeInfo to enable direct
field-style access of ScopeFlags, removing some dead code in
the process.
* Allow implicit FromConstexpr conversion from subtypes of
'constexpr A' to other types. This makes it possible/easy to
convert constexpr versions of enums to other types, since the
constexpr version of the enum isn't addressable. It's namespace
isn't a valid namespace and is an implementation detail anyway.
* Cleanup LanguageMode: Language mode is now an enum and directly
mirrors the C++-side definition rather than being a Smi. With
the changes above, a new type LanguageModeSmi is introduced
that is the Smi representation of LanguageMode that can be
implicitly casted from constexpr LanguageMode values.
Change-Id: I190412f95e02905f445d149883fbf1f2b8ed757b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1977159
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65561}
The spec was normatively changed to simplify var scopes for parameter
expressions. Previously there was a per-parameter var scope in sloppy
mode so direct evals could introduce vars that did not escape the
parameter position. That semantics is complex both for the programmer
and implementation and has resulted in bugs in the past. Furthermore, it
has never been fully interoperable (with Safari in particular). The spec
was instead changed to be simpler: to have a single var scope for
sloppy evals in parameters that encloses the parameter scope and body
scope.
This simplification lets us remove expression-scope-reparenter.
Drive-by removal of stale reference to PatternRewriter.
Bug: v8:7532
Change-Id: Iade5594abe0009f7f3f6a1adad18628b17e1e779
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962471
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65517}
Also port a few smaller functions.
Bug: v8:9838
Change-Id: I2245abe648378970a89331baa19af49f7f49359b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1961942
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65510}
This CL adds an argument to the heap profiler that allows to control
whether global objects (e.g. 'window' in JavaScript) are treated as
roots in the heap snapshot. Doing so hides blink-internal details and
is often a good choice when user-JS leaks are investigated. Sometimes,
however, this introduces spurious retainer cycles, which are hard to
debug.
Previously, this option was exposed as a V8 flag. The blink
implications of the build-time V8 flag are now available via
the new blink flag `enable_additional_blink_object_names`.
Tbr: hpayer@chromium.org
Bug: chromium:1034504
Change-Id: Ibe9412917ae598a3ff0c3dc956ab0bc179f50a21
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967387
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65491}
This is a reland of 5f5b4b0407
Original change's description:
> Support Intel VTune ITT API
>
> Add VTune domain support extension to use VTune Domain/Task API and
> tagging trace data for particular JS code block.
>
> How to use:
> 1. Set `"checkout_ittapi" = True` in the custom_vars section of .gclient
> file to download intel/ittapi by 'gclient sync'
> 2. Build d8 with gn build flag 'v8_enable_vtunetracemark = true'
> 3. Run d8 with flag '--enable-vtune-domain-support'
>
> The Vtune Domain/Task API can be invoked from JS to mark JS code block.
> You can mark the start of a JS task by
> vtunedomainmark(domain_name, task_name, "start")
> and the end of a task by
> vtunedomainmark(domain_name, task_name, "end")
> Tasks can nest.
>
> The VTune API (ittapi) is integrated as an external third party library
> while the v8_vtune_jit also relies on the VTune ittapi. We have another
> patch almost ready which refactors the v8_vtune_jit related code to
> depend on the third_party/ittapi. We will submit the refactored v8_vtune_jit
> code after this patch stabilized and landed.
>
>
> Contributed by fanchen.kong@intel.com
>
> Change-Id: I0ecc9dd4e1ea52545f1b6932fcdadfa7c1a6d2b2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1938490
> Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65409}
Change-Id: I563aa70fa2b8abe34c981af47aa7220cfc2a7edb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1963511
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65478}
Add pointer-sized field extension to the JSArrayBuffer class. Only
reserve space for this field when feature is enabled for now.
Bug: v8:10064
Change-Id: Idb6fdcdce2a048e6aed9a892bc46ce029e1119f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1956166
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65471}
This unifies marking worklists handling by the main thread marker and
by the concurrent markers. A new class called MarkingWorklistsHolder
owns all marking worklists: the default worklist, the on-hold worklist,
and the embedder worklist. Each thread creates a local view of the
marking worklists by creating an instance of MarkingWorklists.
Additionally, marking visitors now work on MarkingWorklists instead of
accessing each worklist individually.
Besides cleaning the code up, this CL provides a bottleneck for
implementing per-context worklists.
Bug: chromium:973627
Change-Id: I52ad65c94bc0695287ba7bf4d8a814a9035e2888
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1941947
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65421}
This reverts commit 5f5b4b0407.
Reason for revert: Breaks vtunejit bot - see https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20vtunejit/32958
Original change's description:
> Support Intel VTune ITT API
>
> Add VTune domain support extension to use VTune Domain/Task API and
> tagging trace data for particular JS code block.
>
> How to use:
> 1. Set `"checkout_ittapi" = True` in the custom_vars section of .gclient
> file to download intel/ittapi by 'gclient sync'
> 2. Build d8 with gn build flag 'v8_enable_vtunetracemark = true'
> 3. Run d8 with flag '--enable-vtune-domain-support'
>
> The Vtune Domain/Task API can be invoked from JS to mark JS code block.
> You can mark the start of a JS task by
> vtunedomainmark(domain_name, task_name, "start")
> and the end of a task by
> vtunedomainmark(domain_name, task_name, "end")
> Tasks can nest.
>
> The VTune API (ittapi) is integrated as an external third party library
> while the v8_vtune_jit also relies on the VTune ittapi. We have another
> patch almost ready which refactors the v8_vtune_jit related code to
> depend on the third_party/ittapi. We will submit the refactored v8_vtune_jit
> code after this patch stabilized and landed.
>
>
> Contributed by fanchen.kong@intel.com
>
> Change-Id: I0ecc9dd4e1ea52545f1b6932fcdadfa7c1a6d2b2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1938490
> Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65409}
TBR=machenbach@chromium.org,hpayer@chromium.org,verwaest@chromium.org,shiyu.zhang@intel.com
Change-Id: I44a6e5b1aa32e753ae41966ed321ed787cc752f8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1960291
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65410}
Add VTune domain support extension to use VTune Domain/Task API and
tagging trace data for particular JS code block.
How to use:
1. Set `"checkout_ittapi" = True` in the custom_vars section of .gclient
file to download intel/ittapi by 'gclient sync'
2. Build d8 with gn build flag 'v8_enable_vtunetracemark = true'
3. Run d8 with flag '--enable-vtune-domain-support'
The Vtune Domain/Task API can be invoked from JS to mark JS code block.
You can mark the start of a JS task by
vtunedomainmark(domain_name, task_name, "start")
and the end of a task by
vtunedomainmark(domain_name, task_name, "end")
Tasks can nest.
The VTune API (ittapi) is integrated as an external third party library
while the v8_vtune_jit also relies on the VTune ittapi. We have another
patch almost ready which refactors the v8_vtune_jit related code to
depend on the third_party/ittapi. We will submit the refactored v8_vtune_jit
code after this patch stabilized and landed.
Contributed by fanchen.kong@intel.com
Change-Id: I0ecc9dd4e1ea52545f1b6932fcdadfa7c1a6d2b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1938490
Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65409}
This CL adds build flags for pluging in third-party heap implementation.
Additionally it redirects allocation requests when the flags are on.
Bug: v8:9533
Change-Id: I7ef300ca9dc2b5f498a13211611ae4b4b3df8fa0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928860
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65114}
This CL adds one undeclared "torque_base" header, as well as two
headers that are generated by the Torque compiler itself.
R=tebbi@chromium.org
Bug: v8:9810
Change-Id: I76c552d897da08b47c03efba959b348f0c2e5843
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1918256
Auto-Submit: Simon Zünd <szuend@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65009}
utils.h itself is fairly large and contains lots of unrelated functions
as well as having a fair number of dependencies itself, so this splits
bounds checking and bit field operations into their own headers in base
and replaces uses of utils.h with the more appropriate header where
possible. (Also fixes some cases where other headers were previously
brought in transitively).
Bug: v8:9810, v8:8912
Change-Id: I76c53f953848a57e2c5bfad6ce45abcd6d2a4f1b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916604
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64983}
This reverts commit 64c09f67d2.
Reason for revert: We already support up to max int32 sized TypedArrays
regardless of the smi size, so the chromium:1009439 issue should no longer be a blocker.
Original change's description:
> [ptr-compr] Temporarily disable 31 bit Smis on 64-bit architectures
>
> The reason is to unblock M79 blocked by chromium:1009439 while full
> solution is not ready yet.
>
> This CL will be reverted after the M79 branch point.
>
> Bug: v8:9767, chromium:1009439
> Change-Id: I5302d86fe953ecd94d9a4bba0d29c807b7b9d703
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862554
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64286}
Bug: v8:9767, chromium:1009439
Change-Id: I92c43c8b27feb4f99e948bca03551e3e0316f2b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916692
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64971}
