Compress the parameter count (and function length) stored in
SharedFunctionInfo to a uint16_t. This limits us to 2^16 - 1 parameters
per function, minus one for the "don't adapt arguments" sentinel value,
which is one fewer than Code::kMaxArguments was already. Anyway, 65534
arguments should be enough for anyone!
This drops SFI size by 4 bytes.
Bug: chromium:818642
Change-Id: I126bfb24453dcdc5087a104d3a12cf195a56fa9f
Reviewed-on: https://chromium-review.googlesource.com/1076627
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53447}
We use name of the function at the moment of first appearance of given
function in stack trace. Any further name changes would be ignored.
It gives us around 20% speedup.
Perf analysis: https://bit.ly/2wp99vtR=yangguo@chromium.org,jgruber@chromium.org
Bug: v8:7078
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I9f21f0bd9cd923e5abaeffb9209df0be2f49afff
Reviewed-on: https://chromium-review.googlesource.com/1050984
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53446}
New intstrumentation consists of:
- kAsyncFunctionSuspended when async function is suspended on await
(called on each await),
- kAsyncFunctionFinished when async function is finished.
Old instrumentation was based on reusing async function promise.
Using this promise produces couple side effects:
- for any promise instrumentation we first need to check if it is
special case for async function promise or not - it requires
expensive reading from promise object.
- we capture stack for async functions even if it does not contain
awaits.
- we do not properly cancel async task created for async function.
New intsrumntation resolved all these problems as well as provide
clear mapping between async task and generator which we can use later
to fetch scope information for async functions on pause.
R=dgozman@chromium.org,yangguo@chromium.org
Bug: v8:7078
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ifdcec947d91e6e3d4d5f9029bc080a19b8e23d41
Reviewed-on: https://chromium-review.googlesource.com/1043096
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53445}
In Torque, we have several global singleton classes. Using the contextual
variable pattern instead of passing around pointers in random places
makes the code more readable.
This CL does this for TypeOracle, we plan to do it for more classes in
the future.
Bug: v8:7754
Change-Id: Ib744b476ce51a4932c52274b2210149515f1663d
Reviewed-on: https://chromium-review.googlesource.com/1078729
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53444}
GCC 5.4 complains type mismatch as follows:
../../v8/src/contexts.cc:302:34: error: format '%hhu' expects
argument of type 'int', but argument 3 has type
'v8::internal::VariableMode' [-Werror=format=]
Bug: chromium:841460
Change-Id: Id90c1211f459309e477a8ad5658cecdf9cc10938
Reviewed-on: https://chromium-review.googlesource.com/1077051
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#53443}
The MathPowInternal builtin is now only called directly from the
code-generator. Also, this patch takes the opportunity to cleanup the builtin
for arm and arm64 a little.
Change-Id: If53edcecd42b227ef74ee817bc5d7fbbcea8b0e2
Reviewed-on: https://chromium-review.googlesource.com/1076127
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#53442}
With this CL we use interrupt for pause in two cases:
- when we process Debugger.pause on interruption,
- when we would like to break as soon as possible after OOM.
In all other cases, e.g. for async step into we use break
on function call by calling StepIn debugger action.
In mentioned cases we should not actually use interrupt as well:
- Debugger.pause in this case scheduled using interrupt and we
may just break right now without requesting another interrupt,
unfortunately blink side is not ready,
- we should use more reliable way to break right after near OOM
callback, otherwise we can get this callback, increase limit,
request break on next interrupt, before interrupt get another
huge memory allocation and crash.
There are couple advantages:
- we get much better break locations for async stepping
(see inspector tests expectations),
- we can remove DEBUG_BREAK interruption
(it should speedup blackboxing with async tasks, see
removed todo in debug.cc for details)
- it is required preparation step for async step out,
(see https://chromium-review.googlesource.com/c/v8/v8/+/1054618)
Bug: v8:7753
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Iabd7627dbffa9a0eab1736064caf589d02591926
Reviewed-on: https://chromium-review.googlesource.com/1054155
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53439}
https://crrev.com/c/1075047 introduced a bug on mips/mips64 in which
sp and fp offsets were set incorrectly for INTERNAL frames.
Bug: v8:6666,chromium:847728,chromium:847568
Change-Id: I9a48d30a82f10a4af50f1ed4dc1d77e8defbdd77
Reviewed-on: https://chromium-review.googlesource.com/1078109
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53434}
Extends the functionality of Managed<T> to track an estimated size
for the external memory associated with an instance of Managed<T>
in order to allow for proper accounting in the garbage collector.
R=mstarzinger@chromium.orgCC=ulan@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I8c49c6245eaf267c9264ebb93b43d5dfbf4671fd
Reviewed-on: https://chromium-review.googlesource.com/1076332
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53433}
This extends the ScriptCompiler::CompileModule function with a
CompileOptions argument. Accepted values are kNoCompileOptions (in
which case, behavior remains unmodified) and kConsumeCodeCache. If the
latter is passed, we try to fetch the given module from the code
cache.
Since it is possible to compile the same source code as both a script
and a module (and different code is generated for the two cases), a
new is_module bit is added to the SerializedCodeData header to
disambiguate between the two cases.
Bug: v8:7685
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I34b3642505577ed9ed0caedbee5876308c5a53ea
Reviewed-on: https://chromium-review.googlesource.com/1073327
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53432}
builtins_util.h declares a macro named CHECK_RECEIVER and in some
extreme jumbo build configurations, that macro will end up in the
same translation unit as runtime-dataview.cc
Bug: v8:7792
Change-Id: I6db865b6061afd6bf1c74b3a172485d68c749929
Reviewed-on: https://chromium-review.googlesource.com/1075052
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53430}
Document what pieces of data the global `FutexEmulation::mutex_`
mutex protects from concurrent access, and reduce the scope
in which said mutex is locked during `FutexEmulation::Wait()`
to match that description more closely.
Change-Id: I0764efabac06814d83ed5c4af4eb7da34af47cab
Reviewed-on: https://chromium-review.googlesource.com/1074689
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53429}
This CL fixes a bad interleaving that can happen between the
CompilationState and streaming compilation. In that particular
interleaving, streaming compilation tries to restart compilation tasks
after compilation failed already, which fails with a check in the
CancelableTaskManager. The problem is the following:
The CompilationState notifies the streaming decoder of compilation
errors. After receiving the notification, the streaming decoder
ignores all subsequent incoming bytes. However, the CompilationState
does not notify the streaming decoder directly, it posts a task
which will notify the streaming decoder. This means that between the
failing of compilation and the notification of the streaming decoder
there is a time window in which compilation already failed but the
streaming decoder can still restart compilation tasks. The crash
happened when this time window was hit.
With this CL we check that compilation did not fail before we restart
compilation tasks. I was never able to reproduce this crash, so I don't
really know if this particular issue caused the crash.
R=titzer@chromium.org
Bug: chromium:840713
Change-Id: Ic522b1c21a7d7749c1e7f6097aa450a09fb271cc
Reviewed-on: https://chromium-review.googlesource.com/1075787
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53428}
Port 757631830d
Original Commit Message:
The code slot of internal frames seems to be basically unused.
As always, there are exceptions:
1. In elements.cc we check whether the current code object is the apply
builtin. We can use a heap lookup through the frame's pc instead.
2. In isolate.cc we store a reference to the frame's code object to try
and pack it into the minidump. This can safely be skipped.
Remaining use-sites in frames.cc all skip INTERNAL frames by using the
JavaScriptFrameIterator.
R=jgruber@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I3612b206f25b9e53645d2e1bc726a5e318a1f4be
Reviewed-on: https://chromium-review.googlesource.com/1076505
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#53427}
Port b2abe2cf97
Original Commit Message:
This makes the WasmCompileLazy builtin push a new WASM_COMPILE_LAZY
frame type. We can thereby remove the workaround to return a relocated
instance from the underlying runtime function. It also removes the last
remaining embedded code objects from {WasmCode} objects.
R=mstarzinger@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Icdc1ee06a1fade4bb805ae0fadf8219316731cd7
Reviewed-on: https://chromium-review.googlesource.com/1076529
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#53426}
This is no longer needed now that Wasm is more aggressive about
collecting old memories. It also causes problems with the upcoming trap
handler fallback path.
Change-Id: I4b8513c28e0c0d7c6b232d399c1d97b645499ef1
Reviewed-on: https://chromium-review.googlesource.com/1043277
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53425}
This CL switches to the new taskrunner API in the MemoryReducer. We
want to remove the old API eventually so that there is only one API for
task posting.
R=ulan@chromium.orgCC=gab@chromium.org
Change-Id: I1dd16e42dc0fca013a97c76dfce9c6479b97521b
Reviewed-on: https://chromium-review.googlesource.com/1061531
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53422}
This CL creates the "tools/torque" directory. It moves the existing
two scripts (making the parser and formatting Torque code) into that
director.
The extension lives in "tools/torque/vscode-torque" and currently only
provides basic syntax highlighting support. The easiest way to
install the extension is to simply create a symlink into your local
vscode extension directory (see README.md).
R=jgruber@chromium.org, tebbi@chromium.org
Change-Id: Ifc22b615341ed18f91c9b046090f569fcc083ab6
Reviewed-on: https://chromium-review.googlesource.com/1076548
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53421}
The regression test 2185-2 measured the Array.p.sort time for various
pre-sorted data configurations. This CL adds the various data
configurations to the ArraySortPreSorted benchmark and removes the
regression test altogether.
R=cbruni@chromium.org, jgruber@chromium.org
Change-Id: I6e2eb235e4a7578f4a107229bfc6a9e89a3aa5e3
Reviewed-on: https://chromium-review.googlesource.com/1076188
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53420}
This CL is a proposal to add "checked" casts (CAST in CSA) to the Torque language.
The CL adds the "unsafe_cast<>" operator that emits a "CAST".
Example:
let n: Number = ...;
...
if (TaggedIsSmi(n)) {
let m: Smi = unsafe_cast<Smi>(n);
...
}
The cast wont incur a runtime overhead now.
R=tebbi@chromium.org
Change-Id: I9fca90d1d11e61617ba0270e5022fd66200e2195
Reviewed-on: https://chromium-review.googlesource.com/1070151
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53416}
This adds a convenience overload for `EscapableHandleScope::Escape()`
which moves `MaybeLocal<T>`s into the outer scope, like a regular
`Local<T>`.
This basically moves the syntactic clutter of having to write
`maybe_local.FromMaybe(Local<Foo>())` instead of just `maybe_local`
to a central location.
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I1d87d75c6564b10e8ec34957bdd3eac46ffea917
Reviewed-on: https://chromium-review.googlesource.com/1056529
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53415}
This change fixes the usage message of arm, mips, mips64, ppc and s390
simulators.
Change-Id: Ib00d3049cb1c81c2653ee8b66d21eabde8f16f76
Reviewed-on: https://chromium-review.googlesource.com/1059623
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53414}
see crbug.com/841460 , we recently hit some build issues when using
Goma + jumbo builds because of a conflict on the definition of CONST,
v8 defines it in globals.h and including windows.h also defines it. It
should be possible to fix this by adding a bunch of #undef CONST but it
seems a little bit hacky and might not always work (this could only fix
the problem temporary if the jumbo merge limit changes and cause some
include files to get included in a different order).
Renaming the v8 definition of CONST to kConst, this follows the
style guide guidelines: "there is no reason to change old code to use
constant-style names, unless the old names are actually causing a
compile-time problem"
(https://google.github.io/styleguide/cppguide.html#Enumerator_Names)
I also had to turn the PropertyConstness enum into an enum class to
avoid some conflicts (both PropertyConstness and VariableMode define
kConst).
Bug: chromium:841460
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I2b70b9095374e88a5ae364cc557b39f20a3ab60f
Reviewed-on: https://chromium-review.googlesource.com/1064197
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sébastien Marchand <sebmarchand@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53413}
This adds support for union types to Torque.
There is a new type expression
A | B
to form the union of the type expressions A and B.
This is only possible if A and B have a common supertype, to prevent
nonsensical unions of types with different representations.
Union types are normalized:
A | B == B | A
A | (B | C) == (A | B) | C
A | A == A
The subtyping rules are defined recursively:
(A | B) <: C if A <: C and B <: C
A <: (B | C) if A <: B or A <: C
This allows to define Object as a union type:
type Tagged generates 'TNode<Object>';
type Smi extends Tagged generates 'TNode<Smi>';
type HeapObject extends Tagged generates 'TNode<HeapObject>';
type Object = Smi | HeapObject;
The type {Tagged} is introduced to have a common supertype of all
tagged values, but we should not use it directly, because {Object}
contains the additional information that there is nothing but {Smi}
and {HeapObject} values.
When mapping union types to CSA types, we select the most specific
common supertype. For Number and Numeric, we already use union types
on the CSA side. Since it is not possible to map to CSA union types
in general, we special-case these two union types to map them to
the CSA union types we already use.
Bug: v8:7793
Change-Id: I7a4e466436f55d04012f29ef17acfdb957653908
Reviewed-on: https://chromium-review.googlesource.com/1076132
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53411}
The code slot of internal frames seems to be basically unused.
As always, there are exceptions:
1. In elements.cc we check whether the current code object is the apply
builtin. We can use a heap lookup through the frame's pc instead.
2. In isolate.cc we store a reference to the frame's code object to try
and pack it into the minidump. This can safely be skipped.
Remaining use-sites in frames.cc all skip INTERNAL frames by using the
JavaScriptFrameIterator.
Bug: v8:6666
Change-Id: I93c5035812838bbae5109415450915db12497b9c
Reviewed-on: https://chromium-review.googlesource.com/1075047
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53409}
This removes the last embedded objects from {WasmCode} objects. We still
embedded the {undefined} value into Wasm-to-JS wrappers, those are now
loaded from the instance object similar to {null} values. The relocation
information for {WasmCode} now no longer contains {EMBEDDED_OBJECT} as
entries anywhere. Another step towards making code Isolate independent.
R=titzer@chromium.org
BUG=v8:7424
Change-Id: I720cd0230948f2063770595ceded373d9bb1e87d
Reviewed-on: https://chromium-review.googlesource.com/1075268
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53408}
This CL further optimizes the decoding fastpath by moving feature
checks off the critical path. For prototype opcodes that are enabled
by feature flags, they are handled in a switch case off the main
path.
R=mstarzinger@chromium.org
Change-Id: If40fedbaadb9c611c78bc2b7df035ced056cb39a
Reviewed-on: https://chromium-review.googlesource.com/1076187
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53406}
This makes the WasmCompileLazy builtin push a new WASM_COMPILE_LAZY
frame type. We can thereby remove the workaround to return a relocated
instance from the underlying runtime function. It also removes the last
remaining embedded code objects from {WasmCode} objects.
R=titzer@chromium.org
Change-Id: Ic9c3f59339e8d7bed53ea0ed70ef50dfe640f1c6
Reviewed-on: https://chromium-review.googlesource.com/1073455
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53405}
A previous CL (https://chromium-review.googlesource.com/c/v8/v8/+/1075056)
introduced an optimization the spill slot where the WASM instance
is stored using the "secondary parameter location" mechanism used for
JS functions and contexts. However the optimization checked the full
machine type of the parameter, which was too narrow. As a result,
the optimization never activated. This CL fixes that by only
checking the machine representation.
R=mstarzinger@chromium.org
Change-Id: I60813935c8d119d2ddf794c797dad314b99ea867
Reviewed-on: https://chromium-review.googlesource.com/1076008
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53403}
Calls from embedded builtins to stubs are expensive due to the
indirection through the builtins constants table. This moves
all remaining Array constructor stubs to builtins.
Bug: v8:6666
Change-Id: I5989a7480697a506a1bae1929ddd2e3f1d655048
Reviewed-on: https://chromium-review.googlesource.com/1074759
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53399}
