This is a reland of a6eabacfee. We
decided that this feature needs more work.
Bug: v8:9088
Change-Id: I937f722e9356be5eca72cdf1edd552d132ee25be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701855
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62715}
This is a convenience flag to trace and debug invalidations. The
assumption used to be that protectors are rarely invalidated, but this
may happen more frequently than expected in practice.
Bug: v8:9463,v8:9466
Change-Id: Ice051593bda647070bc48d535edd03ba96c7dfcd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695469
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62714}
This reverts commit 060b9ec4a8, as the
issue has been resolved.
Bug: v8:7790
Change-Id: Id8a56ad50a508eacd191f2777cc5afc0b838364f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1700078
Commit-Queue: Georg Neis <neis@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62713}
The bytecode graph builder may insert additional jumps for the
SwitchOnGeneratorState bytecode and for loop headers. This plays into
what the graph builder considers dead/alive. We want the serializer to
process all the bytecodes that the graph builder will process, so the
serializer needs to do something similar.
Bug: v8:7790
Change-Id: I1f1d51f4a8951149e365b3c998cef7f613bb4953
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1647694
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62712}
When --concurrent-inlining is on, run bytecode analysis for all relevant
functions at serialization time, and store the results in the broker.
Change bytecode analysis such that running it for OSR produces information
that subsumes the non-OSR case. This lets us avoid doing and storing two
analyses for the top-level function in case we do OSR and the function
gets inlined into itself.
Bug: v8:7790
Change-Id: I7d5df0b2652e6e5c758c85578e51b4f8d041b0d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1690959
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62711}
When passing promises from other contexts to an `await`, the
--harmony-await-optimization doesn't kick in, and as such the
promise will be wrapped in a "native promise" (from this context).
That means the promises aren't chained immediately, but delayed
via a PromiseResolveThenableJob, which chains these promises on
the next turn of this contexts' microtask queue.
If there's anything happening on the macro task queue in between
this and the point when an exception is raised, the chaining will
have happened and we actually find our way back via the promise
chains. And this CL adds support for exactly that case. For other
cases, it's currently impossible to reconstruct the async stack
unfortunately, but we hope that this will help with the major
use cases, where the developer awaits on I/O.
Bug: v8:7522, v8:8673, v8:9487
Ref: nodejs/node#28680
Change-Id: Icc06c7df12644c2d8d43b6c7580ee06bb8f1024a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701847
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62709}
The object itself is already decompressed, and we're simply re-decompressing by
nuking the upper bits through sign extension.
Additionally this CL changes the branchless decompression sequence on x64 to be
cmov-based since that's shorter and faster. It's still slower than branchful
though, so we likely won't use it.
Change-Id: Ie6f9d38fb390b7300a236bf85d0db58d1ee959b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701842
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62708}
We had both jump slots and lazy compile slots in the same table. This
increases the space per slot to the maximum of the two, even though we
often do not use lazy compilation and could have smaller jump slots.
This CL splits the two into two separate tables. The lazy compile table
will only be created on demand, and will never be patched.
The jump table now only contains jumps, and is more compact (which
might improve performance because of improved locality).
R=mstarzinger@chromium.org
Bug: v8:9477
Change-Id: Ie182873a1ec612f71d1b54447021a9a8f8ca59db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698393
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62707}
... by making them const or converting them to pointers.
Bug: v8:9429
Change-Id: If4a7832944f5dc35cec04c11087499a552a7469a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1700073
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62705}
We never call GetTraceRecordMode() on the TraceConfig produced in D8
but instead always create the default ring buffer.
That means we ignore the "record_mode" argument supplied in config json
file.
Given we never use this we can remove the parsing code. The same thing
is true for enable_systrace and enable_argument_filter. All of these
are never used in V8 (they were copied from Chrome) but are part of the
public API so this CL just removes our parsing code for them but leaves
them in the API for now.
Bug: v8:8339
Change-Id: Iab5169536e20c19a784a55d013765125dd701773
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698397
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62704}
According to the specification, class-specific {operator new} and
{operator delete} should be static methods. Interestingly, if the
{static} keyword is missing, the methods are implicitly static anyway.
This is confusing, so this CL adds the {static} keywords explicitly.
It also removes the redundant {Malloced::New} and {Malloced::Delete}
methods.
R=mlippautz@chromium.org
Bug: v8:9396
Change-Id: I1db7c87b816567cc1a9153d0b18e3dd4ae81dd6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1700080
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62703}
This test no longer fails with concurrent inlining.
(Concurrent inlining is actually disabled in 'future' at the moment
but will be turned on again soon.)
Bug: v8:9094
Change-Id: I4d3f8021a7accff8cd670f3fef95a7995f1a9ba7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1700076
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62702}
This CL introduces new non-speculative operators BigIntAdd
and BigIntNegate. Instead of keeping speculative operators
until effect-control-linearization phase, they are now lowered
to non-speculative variants in the simplified lowering and
surrounded by the necessary checks. This adapts BigInt operators
to the common style of other operators (like Numbers).
Bug: v8:9407
Change-Id: I89ea7aef0d78c67b103971f8f63525b196ad3c0c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695467
Commit-Queue: Nico Hartmann <nicohartmann@google.com>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62699}
Problem description:
For prefixed WASM opcode, opcode prefix is printed as Unknown, not the opcode itself.
Take v128.load as an example:
before fix -> after fix
Unknown, 0x00, 0x04, 0x00, -> kExprS128LoadMem, 0x04, 0x00,
Change-Id: Id0cc5c723d19f60ad4f4f6c6ca338b5658c98c7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1694613
Commit-Queue: Jie Pan <jie.pan@intel.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62697}
This reverts commit 13a04abacd.
Reason for revert: Breaks v8 roll (https://chromium-review.googlesource.com/c/chromium/src/+/1698024)
Original change's description:
> fix: move V8_EXPORT_PRIVATE marks to prevent unresolvable references
>
> This change fixes missing symbol errors in the Windows 10 on ARM build
> of Node.js.
>
> When a whole class is marked for export, all of its members are marked
> as well. This can be a problem when inline members call undefined yet
> inline members of other classes: the exported function will contain a
> reference to the undefined inline function that should be satisfied at
> link time, but because the other function is inline no symbol will be
> produced that will satisfy that reference.
>
> Clang gets around this by masking inlined class members from export
> using /Fc:dllexportInlines-. This is why b0a2a567 worked.
>
> Node.js' Windows builds use MSVC and so do not have access to this
> flag. This results in unresolved symbols at link time.
>
> Bug: v8:9465
> Change-Id: Ief9c7ab6ba35d22f995939eb62a64d6f1992ed85
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1696771
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62660}
TBR=sigurds@chromium.org,jgruber@chromium.org,ishell@chromium.org,jkunkee@microsoft.com
Change-Id: Ief2ccb35fc19b00975e78a63791a558525d49ee9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9465
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1700069
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62694}
...from the Store constructor/destructor. They were preventing embedders
from using several Stores with overlapping but non-nested lifetimes.
Without Isolate::Enter, such use cases are supported; the only consequence
is that Isolate::Current will not work and therefore must not be called;
but it is deprecated and not called from the Wasm C API anyway.
Change-Id: I65eda00243126e189febb0fd8b38a953c4ee078f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698387
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62692}
The code to create wrapper modules on the fly was dead already.
The code to read wire bytes has been replaced with accesses to
V8's internal decoded form of the same data.
Change-Id: I736c8467df3ded9de08f2d567dbfd5e695dcfb0e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698384
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62691}
Move to stage for
harmony_intl_dateformat_day_period
harmony_intl_dateformat_fractional_second_digits
after ECMA402 SC reach consensus July 11 2019 to treat them as Stage 3.
Aiming to flip to ship for m78. Just get ready before sending out I2S
after m77 branch off in end of July.
Bug: v8:9283, v8:9284
Change-Id: I9bb145827157af9debc75cc4fc3859a60a5a023c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1699301
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62689}
This CL adds a speculative operator for BigInt negation that is
lowered to the respective builtin call and is optimized to native
64 bit machine operations if truncated. In particular, this change
allows negative BigInt constants (e.g. -5n) to be lowered.
Bug: v8:9407
Change-Id: Ia98fd6dee18a31ce56efbe537f4352b1582539e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695463
Commit-Queue: Nico Hartmann <nicohartmann@google.com>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62684}
The code generated for ChangeUint64ToBigInt in the
EffectControlLinearizer did not initialize the optional padding
field of newly allocated BigInts. This padding field is present
on 64 bit builds without pointer compression enabled. This CL
fixes this by 0-filling the padding field if present.
Bug: v8:9407
Change-Id: I511e163e676dc966a3eb6dfb92b5065e36329225
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695464
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@google.com>
Cr-Commit-Position: refs/heads/master@{#62683}
The bytecode graph builder currently creates the tagged template if
it hasn't yet been done. This CL moves that work to serialization time.
Bug: v8:7790
Change-Id: I9571c5ad2f553584869056fb0cf501e03563d6f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687670
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62681}
Similar to https://chromium-review.googlesource.com/c/v8/v8/+/1697246 but
for the Pointer case.
The three CLs combined bring good improvements to the code generation,
both in code size and then in runtime.
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:7703
Change-Id: I0903df55f3e19d3ee4dddb3c069ddc27b3265cd3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698395
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62678}
Similar to https://chromium-review.googlesource.com/c/v8/v8/+/1697246 but
for the Any case.
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:7703
Change-Id: I99f839faad17da35adac8a084289b1553530d4a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698394
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62677}
In essence, it simplifies the pattern (in x64):
movl register, ___
movlsxlq register, register
into:
movlsxlq register, ___
This makes the code smaller and run faster, without compromising.
We can do something similar for Arm64 too.
The cases for Pointer and Any seem to be trickier but there seems to be
room to improve as well.
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:7703
Change-Id: I583bdfafdae9330be0a08ad1dd4c196e7de2f0d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1697246
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62676}
The serializer clears JSFunctions together with feedback vectors
assuming that there is one to one correspondence between them.
That does not work in the case when there are multiple JSFunctions
sharing the same feedback vector. This patch ensures that all such
JSFunctions are properly cleared.
Bug: v8:7857
Change-Id: Ie441089e12bda5a8be7f9bed90f7be9499938609
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698383
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62673}
Everyone was getting a copy of this through debug.h.
Bug: v8:9396
Change-Id: I5189cb4bf27a3381768b0be479d7b3d60dec20bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695472
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62670}
I noticed the indentation was off in one function, but also fixed
all the other flake8 issues in this file.
Change-Id: I2303ed87da7154484a872315f8355f57621514c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1697054
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Sam Clegg <sbc@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62669}
Previously, we didn't have access checks for the megamorphic case cause
we'd never get to this IC state for a receiver that doesn't hold the
right private field. But now with lazy feedback allocation we share
the megamorphic case code paths for the uninitialized loads as well,
which exposes our bug.
Bug: chromium:982702
Change-Id: I419406bcfc52575260a85d05520c1662735e15f8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1697256
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62668}
This CL adds a new FreeList strategy, that can be turned on by using flag
`--gc-freelist-strategy=1`. It is inspired by FreeListLegacy, and differs from
it in the following ways:
- Only has 3 categories: Medium, Large and Huge.
- Any block that would have belong to tiniest, tiny or small in FreeListLegacy
is considered wasted.
- Allocation is done only in Huge, Medium and Large (in that order), using a
first-fit strategy (only the first block of each freelist is ever considered
though).
- Performances is supposed to be better than FreeListLegacy, but memory usage
should be higher (because fragmentation will probably be higher).
Bug: v8:9329
Change-Id: Ib399196788f1dfaa1aeddc3dc721375dd7da65f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1697248
Commit-Queue: Darius Mercadier <dmercadier@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62667}
