Permit individual calls to CpuProfiler::StartSampling to provide their
own requested sampling interval, to be snapped to the profiler's
sampling interval. Use the greatest common divisor of all sample rates
to determine what sample rate should be chosen for the sampling thread,
and dispatch samples to attached profilers based on their requested
sample periodicity.
Change-Id: I0b076d09761d7176f31725e112578b68ab5da54c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1484461
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Andrew Comminos <acomminos@fb.com>
Cr-Commit-Position: refs/heads/master@{#61548}
All macros defined in "format-macros.h" are dead now (after
https://crrev.com/c/1613243). This CL removes this header, and includes
<cinttypes> instead wherever we use format macros for the types defined
in <cstdint>.
Plus some drive-by cleanup of includes.
R=mlippautz@chromium.org
Bug: v8:9183
Change-Id: Ic379759b79edb50e38833defb1577cc3af7c8150
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611800
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61540}
Internalizing is useful if we expect the string to reoccur many times.
Internalizing too long strings will cost due to hashing, and the resulting
strings will be kept alive for longer. Drop the limit to 10 to be more
conservative.
Change-Id: I2ac2109ca03ab05dbc5c01d4efe6f912b12f65b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611805
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61539}
Use feedback from adjecent array elements to speed up object creation.
Change-Id: Ib5c1b07cc63afb1a4b0cf194144a0ecd31139cb6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1612898
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61538}
This CL adds a check and a more descriptive error message when no "map"
is passed when constructing an extern class:
extern class Foo extends HeapObject {...}
const f = new Foo {};
R=sigurds@chromium.org
Bug: v8:7793
Change-Id: I0dfa6d5976e98d572bafcf7a87f701ea97cd6a73
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611804
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61537}
The 'z' length modifier for {size_t} in format strings was introduced
with C99, hence it is available in all environments we support.
R=jgruber@chromium.org, mlippautz@chromium.org
Bug: v8:9183
Change-Id: I1bc2abec3f9c7b38186128202fef4719853de7d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1613243
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61536}
This CL adds support for all kinds of Types to "textDocument/symbol"
requests. While LSP has support for classes and structs, it does not
have support for generic types. Only classes are marked as such,
while all other types are marked as structs in terms of the LSP.
Special care has to be taken with TypeAliases. Generic call sites
introduce a new scope (similar to namespace scopes), where new
TypeAliases are created for Generic type arguments. These TypeAliases
then point to the specialized type inside this call-site specific
scope. To omit the specialized TypeAliaes from the symbols list,
they are marked using the "is_user_defined" flag.
R=sigurds@chromium.org
Bug: v8:8880
Change-Id: I576d1c677a5255d54f7774aa053f431608a4cd0c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1613240
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Auto-Submit: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61534}
This avoids the need to throw range errors when we run out of stack, limiting
us only by available memory.
The main parser loop is implemented by two subloops.
The first subloop finishes whenever it generates primitive values, empty
arrays, or empty objects. If a non-empty object or array is started, the loop
continues to parse its first member.
The second subloop consumes produced values and either adds them to the parent
array or object, or returns it. The second loop finishes whenever a next value
needs to be produced. When the loop itself produces a finished array or object,
the loop continues.
Exceptions are handled by moving the cursor to end-of-input. Upon end-of-input,
the first loop sets the continuation to "kFail". That causes the second loop to
tear down continuation stack and related handle scopes, resulting in an empty
handle.
The CL additionally buffers all named properties and elements so we can
immediately allocate a correctly shaped object. For object elements we'll take
flat array or dictionary encoding depending on what is more efficient.
This means that element handles are now allocated in their parent HandleScope,
rather than having local handlescopes per-property (of big objects); which is
why I've adjusted the handle-count test to not allocate as many properties. In
the future it would be nice to not have to allocate (as many) handles since
almost everything in the JSON graph will survive JSON parsing...
Bug: chromium:710383
Change-Id: Ia3a7fd0ac260fb1c0e5f929276792b2f8e5fc0ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609802
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61533}
This is a reland of 200a594a63.
The failing DCHECK was wrong, which is fixed now.
Original change's description:
> [wasm][gc] Reenable discarding system pages
>
> On windows, the range to be discarded needs to be split by the
> reservations, analogous to committing. This CL reuses the same logic,
> and reenables discarding pages on all platforms.
>
> R=mstarzinger@chromium.org
>
> Bug: v8:8217
> Change-Id: I11716d6381f765bdfe4cf48502b5cdc1f42cf8ab
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611682
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61526}
Bug: v8:8217
No-Try: true
Change-Id: I293c638a5bc4678591a9c02704770ab54af39bdb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1613248
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61530}
This reverts commit 200a594a63.
Reason for revert: Fails on windows: https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20debug/20310
Original change's description:
> [wasm][gc] Reenable discarding system pages
>
> On windows, the range to be discarded needs to be split by the
> reservations, analogous to committing. This CL reuses the same logic,
> and reenables discarding pages on all platforms.
>
> R=mstarzinger@chromium.org
>
> Bug: v8:8217
> Change-Id: I11716d6381f765bdfe4cf48502b5cdc1f42cf8ab
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611682
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61526}
TBR=mstarzinger@chromium.org,clemensh@chromium.org
Change-Id: I35bfbec222c4ba9e7b5990c02d004f7247b28131
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8217
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611802
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61527}
On windows, the range to be discarded needs to be split by the
reservations, analogous to committing. This CL reuses the same logic,
and reenables discarding pages on all platforms.
R=mstarzinger@chromium.org
Bug: v8:8217
Change-Id: I11716d6381f765bdfe4cf48502b5cdc1f42cf8ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611682
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61526}
On windows, when changing permissions for a range of pages, or
committing or discarding a range of pages, we need to split that range
by the reservations and potentially execute several system calls. This
logic is currently implemented for committing memory.
This CL extracts this to a helper function such that we can reuse this
for discarding a range of pages.
R=mstarzinger@chromium.org
Bug: v8:8217
Change-Id: I65673eebe28362975f0165905d20b97ef7947f56
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611544
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61523}
With very few exceptions, this verifies all skipped write-barriers in
CSA and Torque, showing that the MemoryOptimizer together with some
type information on the stored value are enough to avoid unsafe skipped
write-barriers.
Changes to CSA:
SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the
MemoryOptimizer by default.
Type information about the stored values (TNode<Smi>) is exploited to
safely skip write barriers for stored Smi values.
In some cases, the code is re-structured to make it easier to consume
for the MemoryOptimizer (manual branch and load elimination).
Changes to the MemoryOptimizer:
Improve the MemoryOptimizer to remove write barriers:
- When the store happens to a CSA-generated InnerAllocate, by ignoring
Bitcasts and additions.
- When the stored value is the HeapConstant of an immortal immovable root.
- When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned).
- Fast C-calls are treated as non-allocating.
- Runtime calls can be white-listed as non-allocating.
Remaining missing cases:
- C++-style iterator loops with inner pointers.
- Inner allocates that are reloaded from a field where they were just stored
(for example an elements backing store). Load elimination would fix that.
- Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole).
We could handle that in Torque.
- Double-aligned allocations, which are not lowered in the MemoryOptimizer
but in CSA.
Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this
can be handled by overload resolution (in Torque and C++).
Reland Change: Support pointer compression operands.
R=jarin@chromium.orgTBR=mvstanton@chromium.org
Bug: v8:7793
Change-Id: I84e1831eb6bf9be14f36db3f8b485ee4fab6b22e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1612904
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61522}
In the case of LoadElement in EscapeAnalysis we accidentally always set
the object as escaping, even in the case where the index was a constant
(or had a constant type).
This forced us to always allocate array backing stores even in the
trivial cases like swapping, i.e.
```js
function foo(a, b) {
[a, b] = [b, a];
return a - b;
}
```
Now with this change we do proper scalar replacement again, even for the
array backing stores.
Bug: v8:9183
Change-Id: I3b2dcade23e47df032087778aca1292c8b0d69d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1612907
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61521}
Currently the initial old generation size is set to the half of the
maximum old generation size. This is problematic for huge heaps.
This patch introduces an upper bound of 512MB (256MB) for x64 (x32).
Bug: chromium:961272
Change-Id: If4a6b839ebe688e5b0bc41749ac34f7a31849e21
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605731
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61515}
We used to set disable optimization bits in SFI to NeverOptimize in lite
mode to avoid optimizing in tests. Now, tests that need optimization use
intrinsics to force feedback vector allocation. Hence this is no longer
necessary.
Bug: v8:8394
Change-Id: I0aeaeacc34d838cf15698a9227b6964292b97240
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611545
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61513}
We don't need the full "types" array, just the number of parameters
and the type of the result. Avoiding unnecessary malloc/free calls
significantly cuts down on overhead.
Change-Id: I738f0ee4c269731cf1ff79a56f910e8f7e97c83e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1601505
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61511}
This makes sure the interpreter clears any stale references from the
reference stack when they are popped/dropped. Otherwise stale values
would unnecessarily increase lifetime of operand stack slots.
R=ahaas@chromium.org
BUG=v8:7581
Change-Id: I6b8be56a815327229a66ea0c97b3646ac64f6461
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1612905
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61510}
Previously we had to use CheckHeapObject in front of every CheckMaps,
CompareMaps and TransitionElementsKind operation. Now these operators
request HeapObject representation themselves (requiring for CompareMaps
and TransitionElementsKind to remove the kNoDeopt property). This means
we only do CheckHeapObject for StoreField to a field that has HeapObject
representation.
This not only leads to smaller graphs in the compiler, but also removes
most uses of the CheckHeapObject operator, which doesn't express a real
semantic property in the compiler frontend.
Bug: v8:9183, v8:9250
Refs: nodejs/node#27667
Change-Id: Ie3d83de69583b1bed6c1c53444bfc97aaef624bb
Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1612902
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61508}
The histograms currently mostly contain very small modules (having
0 MB generated and 0 MB freed). Many of those are asm.js modules.
Just recording the modules that are actually interesting for wasm
code GC will give us more meaningful data.
R=mstarzinger@chromium.org
Bug: v8:8217
Change-Id: I1d9ba8134c2f3617f896afc42dc9e87c7852c319
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611679
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61505}
This CL adds a fast path to String#startsWith(s) if s is a
single character string.
Bug: v8:8400
Change-Id: Ibd6a9d1e46d98f41c198d2b579208e25003eedb0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1525362
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61504}
We use the predicate NeedsCheckHeapObject in the compiler frontend to
determine whether we can skip introducing CheckHeapObject nodes. But
this predicate would also walk up the graph in case of Phis, which can
result in really long compilation times (on the main thread). In the
report in https://github.com/nodejs/node/issues/27667, the compiler
frontend alone took around 4-5mins of main thread time for a single
function. With this patch the time goes down to 4-5ms.
Bug: v8:9250
Refs: nodejs/node#27667
Change-Id: I231eb780ff04f949fa1669714f9af6ebfbcade05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1612897
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61503}
Fixes a link error for Windows on Arm component builds.
Change-Id: I848c3aac710b6cbb099011d9c56d7cbc8b5b97fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611683
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61502}
This annotation indicates that the class itself is not instantiated,
and does not have its own instance type: The instance types that
logically belong to the class are the instance types of the derived
classes.
Currently, we need the indication @dirtyInstantiatedAbstractClass
for several classes that are used as both, abstract base classes
and concrete classes. The prime example is JSObject which is the
base for many other classes, and also serves as the class to allocate
plain JSObjects. The annotation is purposefully ugly because in the
future we should refactor code to make it unnecessary.
Another annotation we introduce is @hasSameInstanceTypeAsParent,
which indicates another design pattern that currently occurs in the
code-base: Some Torque classes have the same instance types as their
parent class, but rename some fields, or possibly have a different map.
In such cases, the parent class is not abstract and the derived classes
can be seen as refinements of this class (that, for example, narrows the
type of a field). In the future, Torque should accomodate this pattern
better, but at moment we are content with just indicating where it is
used.
Bug: v8:7793
Change-Id: I1892dcc7325250df75d80308bf3d767d6d43bcc2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1607761
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61495}
When building in debug mode for Windows on Arm, Clang reports the
following error without this patch:
error: attribute 'dllexport' cannot be applied to member of
'dllexport' class.
Change-Id: Ib3b12fce7daa368f9464b080ac7a7bce1ddd5370
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611799
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Richard Townsend <richard.townsend@arm.com>
Cr-Commit-Position: refs/heads/master@{#61493}
This CL introduces the new suffix '-tq' for Torque generated files,
and replaces the infix 'FromDSL' in type names with a prefix
'TorqueGenerated'.
Change-Id: I1e90460cc0c666da6cf5017e8b3cb7c39c6ac668
Bug: v8:7793
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609798
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61490}
Previously we had a special, unshared map on the native context that was
used for results of builtin iterators, which was different from the map
that is created from an object literal like `{value, done}`. This not
only leads to unnecessary polymorphism, but also makes it impossible
for user defined iterators to take the fast-paths that we have in
various places (i.e. in collections or promises).
With this change we now properly share the map for `{value, done}` and
use that for the builtin iterator result objects, as well as the
fast-paths.
Drive-by-fix: Remove the restrictions on map caching and transition
caching during bootstrapping. This no longer makes sense.
Bug: v8:9114, v8:9243
Change-Id: I19eb9071f7ec0ed58f8a6f87eed781bc790174b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609794
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61488}
This CL adds support for macros, builtins, generics and specializations
for the "textDocument/symbol" request. To filter out implicitly
created specializations, the "is_user_defined" flag is hoisted from
Macro to the Declarable super class. As a side-effect, errors thrown
during specialization now have the correct SourcePosition.
Drive-by-change: Using "Goto Definition" on the identifier of the
specialization will jump to the associated generic.
Bug: v8:8880
Change-Id: I0c60571c58107375c1b5d2a8e620cf12a0f0f3fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609795
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61486}
This is a mostly mechanical change that updates the JSTypedArray::length
field to have uintptr_t storage. It doesn't change the allowed ranges
for this field yet, that will be done separately later on.
Bug: v8:4153, v8:7881
Change-Id: Ia4b6f5455bd97b82a4b980d77bda0b09cfa845f5
Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1607647
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61485}
When using the fast-properties optimization for `delete` with constant
fields we don't properly invalidate the constness on the original map
and might thereby just follow the same transition again later with the
same object, effectively violating the constness of that field. This
disables the fast-properties optimization for `delete` in case of a
field marked as "const" as a quick-fix. We might still want to change
the logic to properly invalidate the "const" bit later.
Bug: chromium:962588, v8:9233
Change-Id: I1d0a8649d117731a0cd5ebdb4b6d0b22a900f33d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609796
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61484}