Report the allocated size of global handles in GetHeapStatistics as
well, not including free handles.
Bug: chromium:1060192
Change-Id: I1aedba36735f897cd8518edbb5ef2261cc348bff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093493
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66651}
Suffered from a confusion of masm/marmasm syntax for the x64 host and
arm64 target (could only generate one syntax or ther other). Fixed by
moving the compile-time flag to a runtime one.
Bug: v8:10012
Change-Id: I34746a495b1881c1d0465995930979bb768b07e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962854
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Richard Townsend <richard.townsend@arm.com>
Cr-Commit-Position: refs/heads/master@{#66650}
Rather than having an optional script id during ParseInfo creation (which
is either selected lazily on script creation, or eagerly if based on an
existing Script), always eagerly get either the desired script id (either
from the Script or Isolate::GetNextScriptId()).
This has the side-effect that we will currently no longer need to get the
script id on background threads, but I'm not reverting the thread-safety
of Isolate::GetNextScriptId in case it's needed again in the future.
Bug: v8:10314
Change-Id: I8f2dd962d3652b1a84a5d704a099e57a1679aba5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096616
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66649}
Previously, ParseInfo would create a script (with CreateScript) based on
its flags, and then set its own flags based on that created script. This
created a weird circular dependency for some of those flags, and
sometimes we would have valid flags before script creation (main thread
compile), while other times not (streaming compile).
Now we set the ParseInfo flags manually and uniformly before script
creation, and check that they match the created script after it has been
created.
Bug: v8:10314
Change-Id: Ife886c77727cd228c944a4f97369a3e6365d8219
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093433
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66648}
The arguments order in a JS stack is now controlled by
V8_REVERSE_JSARGS macro.
This CL creates two stubs that allow the order of the arguments
to be reversed without changing CallStub.
Bug: v8:10201
Change-Id: I8f70adf3ced1f45a00f5c4ddd47d5f604f2d3100
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093506
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66647}
Useful for profiling why mksnapshot is so slow in conjunction with
--runtime-call-stats.
Change-Id: Ib193d292352e0019b93c8edccb38a904aadbf553
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089932
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66646}
Torque compiler emits a C++ class definition header
class-definitions-tq.h. Unfortunately it does so in a manner that
introduces randomness into the ordering of some structs. This means that
every full build of V8 may yield a different header.
Since this header is included in a lot of files in V8, it causes a lot
of ccache misses (over a 1000).
This commit makes sure that the structs are emitted in lexical order.
Bug: v8:10310
Change-Id: Ie39066d36e41583ff990bc639f7f241462351585
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093500
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66645}
Port b766299d2c
Port 9592b043ee
Port d915b8d668
Original Commit Message:
Code object iteration was missing logic for RELATIVE_CODE_TARGET
reloc entries. Garbage collection could thus miss objects that were
referenced only as targets of pc-relative calls or jumps.
RELATIVE_CODE_TARGETs are only used on arm, mips, and s390 and only
at mksnapshot-time.
This exposed another issue in that the interpreter entry trampoline
copy we generate for profiling *did* contain relative calls in
runtime-accessible code. This is a problem, since code space on arm is,
by default, too large to be fully addressable through pc-relative
calls. This CL thus also disables the related
FLAG_interpreted_frames_native_stack feature on arm.
objects.
R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Ifbcaed98d90a2730f0d6a8a7d32c621dab1ff5b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087693
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#66644}
Change wrapped argument set-up to be closer to where it's needed: setting
up a top-level SFI, or initializing a ParseInfo from a top-level SFI.
This is a generally cleaner use of the interface, avoids splitting the
setting of the funciton syntax kind and wrapped arguments (including
checking script.is_wrapped() in two places for the same behaviour), plus
it avoids unnecessarily creating wrapped_argument handles for functions
inside a wrapped script.
As a drive-by, rename ParseInfo::SetFlagsFromScript to a clearer
ParseInfo::SetFlagsForFunctionInScript, to differentiate between flags
from a script for top-level vs. non-top-level.
Bug: v8:10314
Change-Id: Ibdaad957558c13a1528dcc3da1ba8f262f357e48
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093509
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66643}
The code was almost compatible, only one small issue had snuck in.
No-try: true
Change-Id: I52225fb2092bf16a5fffbde957cd1dfe4f2c4fd6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093492
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66642}
Non-unicode, case-insensitive regexps (e.g. /foo/i, not foo/iu) use a
case-folding algorithm that doesn't quite match the Unicode
definition. There are two places in irregexp that need to do
case-folding. Prior to this patch, neither of them quite matched the
spec (https://tc39.es/ecma262/#sec-runtime-semantics-canonicalize-ch).
This patch implements the "Canonicalize" algorithm in
src/regexp/special-case.h, and uses it in the relevant places. It
replaces special-case logic around upper-casing / ASCII characters
with the following approach:
1. For most characters, calling UnicodeSet::closeOver on a set
containing that character will produce the correct set of
case-insensitive matches.
2. For a small handful of characters (like the sharp S that prompted
this change), UnicodeSet::closeOver will include some characters
that should be omitted. For example, although closeOver('ß') =
"ßẞ", uppercase('ß') is "SS", so step 3.e means that 'ß'
canonicalizes to itself, and should not match 'ẞ'. In these cases,
we can skip the closeOver entirely, because it will never add an
equivalent character. These characters are in the IgnoreSet.
3. For an even smaller handful of characters, UnicodeSet::closeOver
will produce some characters that should be omitted, but also some
characters that should be included. For example, closeOver('k') =
"kKK" (lowercase k, uppercase K, U+212A KELVIN SIGN), but KELVIN
SIGN should not match either of the other two (step 3.g). To handle
this, we put such characters in the SpecialAddSet. In these cases,
we closeOver the original character, but filter out the results
that do not have the same canonical value.
The computation of IgnoreSet and SpecialAddSet happens at build time,
using the pre-existing gen-regexp-special-case.cc step.
R=jgruber@chromium.org
Bug: v8:10248
Change-Id: I00d48b180c83bb8e645cc59eda57b01eab134f0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2072858
Reviewed-by: Frank Tang <ftang@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66641}
In https://crrev.com/c/2084321 I added s128 load store to the fuzzer,
and updated the memop generator to use IsPrefixOpcode check. But it was
used wrongly. IsPrefixOpcode checks a 1 byte opcode and see if it is a
prefix opcode, but if memory_op is already a 2 byte opcode, it will fail
the IsPrefixOpcode check.
Bug: chromium:1059899
Change-Id: I4caadfb2feaf42ebb9f5578cb790ef8a1d08d173
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2095681
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66638}
When looking for private members in an object for the inspector,
we check if that object is a class constructor with the a bit
has_static_private_methods set on its SFI. If it
is, we look for any variables in the context locals
with a VariableMode associated with private methods or accessors
and a IsStaticFlag being kStatic.
This patch also filters out static private methods when inspecting
instances.
Design doc: https://docs.google.com/document/d/1N91LObhQexnB0eE7EvGe57HsvNMFX16CaWu-XCTnnmY/edit
See also: https://docs.google.com/document/d/14maU596YbHcWR7XR-_iXM_ANhAAmiuRlJZysM61lqaE/edit
Bug: v8:9839, v8:8330
Change-Id: Idad15349c983898de2ce632c38b0174da10e639d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1955664
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#66636}
These two tests was fixed by ICU rolling to 0b6134378
See https://chromium-review.googlesource.com/c/chromium/src/+/2090002
File new bug 10313 to track the unrelated issue in
built-ins/Date/parse/without-utc-offset
Bug: v8:9612, v8:9474, v8:10313
Change-Id: I26f5857f3c4b6000b3585600bc3ed2f2ed29a043
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2095394
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66635}
Bill kindly pointed out to me that v8windbg was not handling bit_field2
correctly. The issue was that the constexpr type for ElementsKind was,
somewhat unsurprisingly, "ElementsKind", but v8windbg expected a fully-
qualified type name like "v8::internal::ElementsKind". This change
addresses the problem in two ways:
1. Update v8windbg's type resolution logic to resolve type names as if
they were used in the v8::internal namespace. This makes it more
consistent with how those type names are used in other generated
Torque code, reducing surprises and the number of times we have to
write `v8::internal::` in .tq files.
2. Add compile-time verification that any constexpr type name used as a
string in class-debug-readers-tq.cc can also resolve as a type name.
Bug: v8:9376
Change-Id: I349cd6ab586fd8345a1fa8bfc3989bb8e6376ab8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2063769
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#66633}
When dst is a fp pair, we set both low and high fp regs. Later when we
look at set regs to determine which registers to load into, we examine
both low and high fp. This is wrong - we only need to look at the low
fp, since Fill will load into the correct fp pairs. The bug was
triggered because we were examining into junk values in register_loads
indexed by the high fp.
Fixed: v8:10307
Change-Id: I6cbc212a969090818a5da0fe3dab36a418c23d04
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091632
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66632}
There exists the pattern in wasm-compiler.cc of allocating a stack slot
and filling it with values. This CL introduces a helper function for
this pattern. Note that not all cases of this pattern can be changed to
use the helper function. In these cases either the size of the stack
slot is not statically known, or the stack slot is also used for return
values.
R=clemensb@chromium.org
Bug: v8:10155
Change-Id: I8497a22fed730424561fc32bc1cfa21643341643
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093495
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66631}
We now always tier down to Liftoff when the debugger is enabled, hence
we don't need to force Liftoff-only execution in the test.
R=thibaudm@chromium.orgCC=duongn@microsoft.com
Bug: v8:9654
Change-Id: I9b9e21b2ee977b349bb4f5d0e34c6ebf82166cb9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093504
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66630}
Bug: v8:7790
Change-Id: Ibdfe1c1a1ad2eb082583285493227fb833be4690
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093501
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66629}
Rolling v8/build: e393474..1739acf
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/b3bfbaa..c5f5b9e
Rolling v8/third_party/depot_tools: ee8be8a..ffd0295
Rolling v8/third_party/icu: 49ee7b1..0b61343
Rolling v8/tools/clang: 101bca1..0f734f7
Rolling v8/tools/luci-go: git_revision:02ba678a47594da180904851f3e6f809da7e0fc5..git_revision:3d22d4e5a77a3d9cbe4b1bf5ed2fc85b61c1e3e6
Rolling v8/tools/luci-go: git_revision:02ba678a47594da180904851f3e6f809da7e0fc5..git_revision:3d22d4e5a77a3d9cbe4b1bf5ed2fc85b61c1e3e6
Rolling v8/tools/luci-go: git_revision:02ba678a47594da180904851f3e6f809da7e0fc5..git_revision:3d22d4e5a77a3d9cbe4b1bf5ed2fc85b61c1e3e6
TBR=machenbach@chromium.org,tmrts@chromium.org
Change-Id: Iba72789d04e02c6dcac6e37df5e66d1e6d079710
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2094658
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#66628}
This CL merges nested loops that share the same header offset with its
parent loop, by not emitting JumpLoop bytecode for these inner loops.
Instead, we generate a Jump to its parent's JumpToHeader (which in
turn can be a JumpLoop or another Jump to its parent's JumpToHeader).
Originally, every loop had a unique first Bytecode to jump to. Since
IterationBody StackChecks are going to become implicit this will no
longer be the case.
As a note, this CL just sets the foundation that the follow-up CLs
will build on top of. Since we have explicit StackChecks, and they
are at the beginning of loops we do not have nested loops as of now.
Bug: v8:10149, v8:9960
Change-Id: I6daee4d2c6d6216f022228c87c4aa74e163997b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062390
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66626}
Considering that the security benefit is unclear at this point, the
performance and binary size costs are not justified.
This CL includes reverts of earlier partial disablings:
173a2bd8b5af7bf14fce85f72be318
Bug: chromium:977230, chromium:1055312, chromium:1055317
Change-Id: I173b61656a542687c4619fa374a0b2ee22c85ef7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091474
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Hablich <hablich@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66623}
String::NewFromLiteral is a templated function that takes a char[N]
argument that can be used as an alternative to String::NewFromUtf8 and
returns a Local<String> rather than a MaybeLocal<String> reducing the
number of ToLocalChecked() or other checks.
Since the string length is known at compile time, it can statically
assert that the length is less than String::kMaxLength, which means that
it can never fail at runtime.
This also converts all found uses of NewFromUtf8 taking a string literal
or a variable initialized from a string literal to use the new API. In
some cases the types of stored string literals are changed from const
char* to const char[] to ensure the size is retained.
This API does introduce a small difference compared to NewFromUtf8. For
a case like "abc\0def", NewFromUtf8 (using length -1 to infer length)
would treat this as a 3 character string, whereas the new API will treat
it as a 7 character string.
As a drive-by fix, this also fixes all redundant uses of
v8::NewStringType::kNormal when passed to any of the String::New*
functions.
Change-Id: Id96a44bc068d9c4eaa634aea688e024675a0e5b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089935
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66622}
In the process:
* Augment C++-generated Torque classes with SizeFor methods to
calculate size of instances.
* Add a new "@generateBodyDescriptor" annotation that causes Torque to
generate C++ BodyDescriptors code that can be used to visit objects
compatible with existing V8 mechanisms, e.g. GC
* Fully automate C++ macro machinery so that adding non-extern Torque
class doesn't require any C++ changes, including ensuring generation
of instance types and proper boilerplate for validators and
printers.
* Make handling of @export a true annotation, allowing the modifier to
be used on class declarations.
* Add functionality such that classes with the @export annotation are
available to be used from C++. Field accessors for exported classes
are public and factory methods are generated to create instances of
the objects from C++.
* Change the Torque compiler such that Non-exported classes implicitly
have the @generateBodyDescriptor annotation added and causes both
verifiers and printers to be generated.
* Switch non-extern Torque classes from using existing Struct-based
machinery to being first-class classes that support more existing
Torque class features.
Change-Id: Ic60e60c2c6bd7acd57f949bce086898ad14a3b03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007490
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66621}
This state can be set on the NativeContext by the embedder. When a
PromiseReaction/PromiseReactionJobTask is constructed, store this
contextual state if present, and restore it while the reaction job
is running.
Change-Id: I141cdbd9e36ea83ce4a6bf08440ae7eaa54523df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2005849
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Nate Chapin <japhet@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66617}
Implement f64x2, i64x2, i8x16 splats on arm and arm64.
Bug: v8:9909
Change-Id: I41f635ae5c6f025ece7f6445a58fbad1ad678fbd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087694
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66616}
Port 820faa6e70https://crrev.com/c/2056468
Original Commit Message:
The arm/arm64 simulators debugger has a command "mem" that prints
the content of the memory. It also prints a short summary for JS
objects (SMI, Array, JSFunction, ...). That is very handy, but
when trying to print incomplete initialized memory, it could raise
an exception.
It is useful to have a command that prints the content of the memory
for non-initialized or bogus values without the risk of raising
an exception. This CL adds the command "dump".
Change-Id: If8c96d7bac4a484c2a4fee9d192a29ea2696580a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089224
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66615}
Prefixed opcodes do not get written correctly in code comments in
Liftoff. The reason is that only one byte is interpreted as the opcode,
but prefixed opcodes take two bytes. This CL loads the second byte if
necessary.
The change could be done in function-body-decoder-impl.h, but that could
lead to performance regressions: it is a hot code path, and the change
here is just for debugging.
R=clemensb@chromium.org
Bug: v8:10155
Change-Id: I2282c068c81b5b1e2e2ed9757f4e77687d1d4ede
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091467
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66613}
Comments on this reservation indicate it may hold either only code pages or code
and data pages if pointer compression is enabled. But in fact it only holds the
reservation for code pages.
Change-Id: Ic007fcadf881153b69dce51db561777cc52685bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091465
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#66612}
The test started failing (sometimes flaking) on an unrelated CL.
R=gsathya@chromium.org
Bug: v8:10307
Change-Id: If198c2cf518f7a36e54614307462272774d9e48e
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091466
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66611}
This CL fixes a special case where a WasmExportedFunction is passed to
the WebAssembly.Function constructor. This is a case that was not yet
implemented in V8, and which is also not specified in the proposal yet.
With this CL we do a signature check of the provided function. If it
matches, the function itself is returned. Otherwise a TypeError is
thrown.
I filed an issue: https://github.com/WebAssembly/js-types/issues/13R=jkummerow@chromium.org
Bug: chromium:1057534
Change-Id: Ib09d1ba18abaa6a8dd451aa747fd26c03d927413
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2084813
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66610}
All other simple C functions take a pointer to a stack slot which
contains the actual parameters, whereas the memory_copy_wrapper takes
three parameters. This makes the code generation from Liftoff more
difficult. This CL changes the signature of memory_copy_wrapper to match
the signature of other simple C functions.
As MemoryCopy and MemoryInit are already implemented with C calls, this
change should not make a big difference in terms of performance. Simpler
and smaller Liftoff code may have more effect on performance. If this
assumption turns out wrong, we can change it in the future.
R=clemensb@chromium.org
Bug: v8:10281
Change-Id: I39e0ea00fcb22b4e84e612fe58eb4642856b72c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078576
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66607}
This adds two new histograms:
- V8.MeasureMemoryDelayMilliseconds measures how long it takes to
serve a memory measurement request
- V8.GCFinalizeMCMeasureMemory is a variant of the existing GC pause
histogram that used when GC runs in memory measurement mode.
Additionally this CL lowers the maximum measurement delay to 10 seconds.
Bug: chromium:1049093
Change-Id: I97cbf443da514a69d6cf8c1d74d2757098e60acd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089937
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66606}
