and also its pure-static subclass PrototypeUsers, whose porting
is a no-op.
Bug: v8:3770
Change-Id: I075806f784a0631058692149e71c45e455e90f73
Reviewed-on: https://chromium-review.googlesource.com/c/1355631
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58003}
This is to address the first issue reported on v8:8453
Page::kPageSize is 524288
MemoryAllocator::GetCommitPageSize() returns 65536 on ppc
ObjectEndOffsetInCodePage() returns 458752
ObjectStartOffsetInCodePage() returns (65536 + 65536) => 131072
Therefore, memory = 327680, which is less than
kMaxRegularHeapObjectSize(507136), which causes the DCHECK to fail.
Bug: v8:8453
Change-Id: I6048192ded4234a6987371ec4d4b2a8553756c25
Reviewed-on: https://chromium-review.googlesource.com/c/1355422
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58001}
- Rename methods,
- Introduce flags for tokens to lookup IsKeyword and IsPropertyName
- Remove "contextual keyword" leftover code.
- Inline ParsePropertyName into ParsePropertyNameOrPrivatePropertyName
since public is more likely than private.
Change-Id: Ib7633ef3c46889ecafc7a6c929029845bb8ef15c
Reviewed-on: https://chromium-review.googlesource.com/c/1357052
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57993}
Also split out some order check tests.
Bug: v8:5751
Change-Id: I1765d1809b456c43e21d9a379f720a0ea12e794e
Reviewed-on: https://chromium-review.googlesource.com/c/1352283
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57988}
The `readonly: true` key-value pair is redundant since it gets
ignored anyhow. This patch removes it.
Also, `configurable: false` is implied when
using `Object.defineProperty` (just like `enumerable: false`
and `writable: false`). Therefore, specifying only `configurable`
but not `enumerable` and `writable` gave the impression that
configurability was somehow the deciding factor for this test.
Instead, the only important data property for this test is
`writable: false`. This patch lists all four data property
attributes explicitly, making it clear that only `writable` has
a “special” value.
Bug: v8:8175, v8:8238
Change-Id: Icfc6262f246712a64cdfcffff7b648f5681a711e
Reviewed-on: https://chromium-review.googlesource.com/c/1357048
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57986}
Taking kSystemPointerSize into account when determining the maximum
allowed BigInt size accidentally made the limit platform-specific.
This patch chooses a platform-independent constant (1<<30) instead.
Bug: chromium:909614
Change-Id: I4717969bc56e6dd5f1eed70b7e60e621989d0719
Reviewed-on: https://chromium-review.googlesource.com/c/1355625
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57983}
This is a reland of 10ea3f8a1d
Original change's description:
> [Compiler] Introduce IsCompiledScope which prevents flushing of compiled code
>
> Introduces a IsCompiledScope object which can be used to check whether a
> function is compiled, and ensure it remains compiled for the lifetime
> of the scope without being uncompiled by bytecode flushing. The Compile
> functions are modified to take a scope so that calling code can ensure
> the function remains compiled for the lifetime they require.
>
> Also, don't allocate a feedback vector for asm-wasm code as this
> is never used, and will be reallocated if the asm-wasm code fails to
> instantiate the module and we fallback to regular JavaScript.
>
> Also restructure Compiler::PostInstantiation() to allocate the feedback
> vector once, and do the optimized code check before optimizing for
> always opt.
>
> BUG=v8:8395
>
> Change-Id: I3f1a71143fcae3d1a0c01eefe91ebb4b8594221a
> Reviewed-on: https://chromium-review.googlesource.com/c/1352295
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57971}
TBR=jgruber@chromium.org,mstarzinger@chromium.org
Bug: v8:8395
Change-Id: I8dc00798a5680997990c879c3380fe4febd47297
Reviewed-on: https://chromium-review.googlesource.com/c/1357045
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57982}
to the new design.
Bug: v8:3770
Change-Id: I63291cc8eccfa1da20e84c6d3e9f48f253409396
Reviewed-on: https://chromium-review.googlesource.com/c/1355627
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57981}
The optimized code for TestSetWithCustomIterator holds a weak reference to the map
for the entries object. If this is collected by the GC then the optimized code deopts
which causes the test to fail. To prevent this, hold onto an entires object to keep
it's map alive.
Change-Id: I5796e74fc1d7c5061bf8c98f7a82fe582d6be76a
Reviewed-on: https://chromium-review.googlesource.com/c/1357043
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57978}
Add the arm architecture to the list of archs that support
Liftoff in mjsunit and so run the Liftoff tests for it.
Bug: v8:6600
Change-Id: I4896f0727f6ccc3343f5d517e100840f76dd901d
Reviewed-on: https://chromium-review.googlesource.com/c/1357040
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57976}
This reverts commit 10ea3f8a1d.
Reason for revert: Causing failure on gc_stress bot:
https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8928421099411850688/+/steps/Bisect_10ea3f8a/0/steps/Retry/0/logs/collections-construct../0
Original change's description:
> [Compiler] Introduce IsCompiledScope which prevents flushing of compiled code
>
> Introduces a IsCompiledScope object which can be used to check whether a
> function is compiled, and ensure it remains compiled for the lifetime
> of the scope without being uncompiled by bytecode flushing. The Compile
> functions are modified to take a scope so that calling code can ensure
> the function remains compiled for the lifetime they require.
>
> Also, don't allocate a feedback vector for asm-wasm code as this
> is never used, and will be reallocated if the asm-wasm code fails to
> instantiate the module and we fallback to regular JavaScript.
>
> Also restructure Compiler::PostInstantiation() to allocate the feedback
> vector once, and do the optimized code check before optimizing for
> always opt.
>
> BUG=v8:8395
>
> Change-Id: I3f1a71143fcae3d1a0c01eefe91ebb4b8594221a
> Reviewed-on: https://chromium-review.googlesource.com/c/1352295
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57971}
TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org
Change-Id: I1449a02a0aceb9757440757628e586df33972a40
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8395
Reviewed-on: https://chromium-review.googlesource.com/c/1357042
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57974}
Introduces a IsCompiledScope object which can be used to check whether a
function is compiled, and ensure it remains compiled for the lifetime
of the scope without being uncompiled by bytecode flushing. The Compile
functions are modified to take a scope so that calling code can ensure
the function remains compiled for the lifetime they require.
Also, don't allocate a feedback vector for asm-wasm code as this
is never used, and will be reallocated if the asm-wasm code fails to
instantiate the module and we fallback to regular JavaScript.
Also restructure Compiler::PostInstantiation() to allocate the feedback
vector once, and do the optimized code check before optimizing for
always opt.
BUG=v8:8395
Change-Id: I3f1a71143fcae3d1a0c01eefe91ebb4b8594221a
Reviewed-on: https://chromium-review.googlesource.com/c/1352295
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57971}
Do not implement one-armed ifs by emulating an empty else branch. In
Liftoff, we can generate better code and save compile time by handling
this specially. If the merge point at the end of the if is not reached
by the if-branch, we do not need to generate any merge code.
R=titzer@chromium.org
Bug: v8:6600, v8:8423
Change-Id: Ie8ea69dd7491f225605a8e1b986d275d869aa90b
Reviewed-on: https://chromium-review.googlesource.com/c/1356508
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57968}
Remove the test-api/InitializeDefaultIsolateOnSecondaryThread_ResourceConstraints
test which was setting max-old-space-size limit without acutally using it. This
caused repetitive failures, resulting in the test being effectively disabled.
Bug: v8:8521
R=ulan@chromium.org, yangguo@chromium.org
Change-Id: Iad39cc95df86963d256816bf56d0bc5f62f7d5c9
Reviewed-on: https://chromium-review.googlesource.com/c/1356506
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57964}
Termination exceptions tear down V8 to the bottom-most V8 call. If there is a
v8::TryCatch scope around that call, it returns true for HasTerminated() and
HasCaught(). However, Isolate::IsExecutionTerminating() returns false and we
can call into V8 from still inside the v8::TryCatch scope.
Changes that this patch introduces:
- You need to leave the v8::TryCatch scope around the bottom-most call to
reset the termination state, in order to resume.
- Explicitly check for termination exception and reporting it through the
DevTools protocol after Runtime.evaluate and Debugger.evaluateOnCallFrame.
Bug: v8:8455
Change-Id: I1f36f7a365985469813c2619bf16f18ee69aa4b8
Reviewed-on: https://chromium-review.googlesource.com/c/1337582
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57963}
The placement of the exceptipon section is by now restricted to be in
between the Global and the Import section. This changes our validation
to check this stricter requirement now.
R=clemensh@chromium.org
TEST=unittests/WasmModuleVerifyTest
BUG=v8:8091
Change-Id: Ib3ea625fd4df93bffda47ced09e6969159f7ac70
Reviewed-on: https://chromium-review.googlesource.com/c/1356504
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57962}
This is a reland of 9436e8a817
This CL simplifies the wasm/futex.js test so that it doesn't push the
limits of d8.
Original change's description:
> [wasm] Add I64AtomicWait implementation
>
> Bug=v8:8075
> R=adamk@chromium.org,binji@chromium.org
>
> Change-Id: I11ef5daccd043123b23e60c93ee0df79cabe9ccd
> Reviewed-on: https://chromium-review.googlesource.com/c/1342948
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Ben Smith <binji@chromium.org>
> Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57917}
Change-Id: Ifd26f1ecdb9fe24a1896162bb4d4285f9188a9ba
Reviewed-on: https://chromium-review.googlesource.com/c/1351304
Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57953}
The bulk-memory proposal adds a new DataCount section that declares the
number of data segments that are expected to be seen in the Data
section. This is similar to the way the number of functions is split
between the Function and Code sections.
The DataCount section occurs before the Code section, so we can do
single-pass validation of the new `memory.init` and `memory.drop`
instructions, which have data segment indices as immediates.
Bug: v8:7747
Change-Id: Ibc5a7ee9336dbc5d0fd667572c42cb065c048e00
Reviewed-on: https://chromium-review.googlesource.com/c/1352792
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57951}
Make sure to check that the number of declared functions (specified in the
function section) matches the number of function bodies, even if the code
section is omitted.
Note that it is valid to have a function section with zero declared functions
and an omitted code section, and vice versa.
Bug: v8:8514
Change-Id: I4effa5abe2ed6d71146a665d2df6a2f48b5a84be
Reviewed-on: https://chromium-review.googlesource.com/c/1351306
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57949}
The problem were missing V8_EXPORT_PRIVATE and V8_EXPORT.
The unittests test if the trap handler only handles those traps it
is supposed to handle:
* Only handle traps when the thread-in-wasm flag is set.
* Only handle traps of the right type, i.e. memory access violations.
* Only handle traps at recorded instructions.
The tests also test the consistency of the thread-in-wasm flag. I made
one change in the trap handler where that consistency could be
violated.
All tests are executed with the default trap handler provided by V8,
and with the trap handler callback installed in a test signal/exception
handler.
Patchset 1 is the original CL.
R=mstarzinger@chromium.org
Change-Id: I172d94f24cdba4c3a1f7f344825b059dbb59da79
Reviewed-on: https://chromium-review.googlesource.com/c/1351024
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57947}
This adds a new target :generated_cc_files which generates all
generated .cc files and is quick to build (~5sec on my machine).
TBR=yangguo@chromium.org
Change-Id: I51485635671b55302b06f1ea300e86ef1745931e
Bug: v8:8526
Reviewed-on: https://chromium-review.googlesource.com/c/1354881
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57941}
This refactors Map operations to update the instance descriptors and
the number of own descriptors via the SetInstanceDescriptors bottleneck.
This will allow us to add a special marking barrier for these updates.
Bug: v8:8486
Change-Id: Ie9c746d4bcdd6166d38402622734693fa59faf21
Reviewed-on: https://chromium-review.googlesource.com/c/1354883
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57934}
Explicitly disallow implicit casting of ObjectPtr to bool to match
clang's and MSVC's behavior.
Introduce a few function overloads using ObjectPtr instead of Object*.
Fix printing of ObjectPtr for objects-printer.cc and GTest.
Bug: v8:3770
Change-Id: I3c3580d363ae6d9fe8f743c6151abc11a915f05c
Reviewed-on: https://chromium-review.googlesource.com/c/1351245
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57928}
This CL marks v8::Isolate::GetEnteredContext as deprecated in favor of
replacing it with GetEnteredOrMicrotaskContext. Blink no longer uses it,
and Node.js does not use this too.
GetEnteredOrMicrotaskContext() is relevant for all known cases over
GetEnteredContext(), and it costs 2% of a benchmark score to maintain
the entered contexts under the nestable microtask context.
https://crrev.com/c/1322290 is a context for the bencmark and nestable
microtask contexts.
Bug: v8:8124
Change-Id: I260e32daadf34dc587926a1e20ab950ff2e31699
Reviewed-on: https://chromium-review.googlesource.com/c/1353025
Commit-Queue: Taiju Tsuiki <tzik@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57927}
This reverts commit ddaa1f0a0d.
Reason for revert:
Still flaky on windows. Maybe reland and keep skipped on windows?
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win32%20-%20nosnap%20-%20shared/31002https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64/27826
Original change's description:
> Reland "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame"
>
> This is a reland of d5f4a33eb8
>
> Original change's description:
> > [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
> >
> > Before fast C calls, store the current FP and PC on the isolate. When
> > iterating frames in SafeStackFrameIterator, check if these fields are
> > set and start iterating at the calling frame's FP instead of the current
> > FP, which will be in C++ code. We need to do this because c_entry_fp is
> > not set on the Isolate for Fast-C-Calls because we don't build an exit
> > frame.
> >
> > This change makes stack samples that occur within 'Fast-C-Calls'
> > iterable, meaning we can properly attribute ticks within the JS caller.
> >
> > Fast-C-Calls can't call back into JS code, so we can only ever have one
> > such call on the stack at a time, allowing us to store the FP on the
> > isolate rather than the stack.
> >
> > TBR=v8-mips-ports@googlegroups.com
> >
> > Bug: v8:8464, v8:7202
> > Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
> > Reviewed-on: https://chromium-review.googlesource.com/c/1340241
> > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
> > Reviewed-by: Alexei Filippov <alph@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#57896}
>
> TBR=v8-mips-ports@googlegroups.com
> TBR=jgruber@chromium.org
>
> Bug: v8:8464, v8:7202
> Change-Id: I5f37ded4ea572e8e9890ba186aa3d74a0dfc1274
> Reviewed-on: https://chromium-review.googlesource.com/c/1354042
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57912}
TBR=alph@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,martyn.capewell@arm.com,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,ibogosavljevic@wavecomp.com
Change-Id: If810648dbf60df2ff70455b6e8ef466136c90145
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8464, v8:7202
Reviewed-on: https://chromium-review.googlesource.com/c/1354461
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57925}
TransitionArray, NormalizedMapCache, DependentCode to the new design.
Bug: v8:3770
Change-Id: I8bd56f231fb62b146e0fb05989418aedb62a628b
Reviewed-on: https://chromium-review.googlesource.com/c/1350287
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57921}
Bug=v8:8075
R=adamk@chromium.org,binji@chromium.org
Change-Id: I11ef5daccd043123b23e60c93ee0df79cabe9ccd
Reviewed-on: https://chromium-review.googlesource.com/c/1342948
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57917}
This is a reland of d5f4a33eb8
Original change's description:
> [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
>
> Before fast C calls, store the current FP and PC on the isolate. When
> iterating frames in SafeStackFrameIterator, check if these fields are
> set and start iterating at the calling frame's FP instead of the current
> FP, which will be in C++ code. We need to do this because c_entry_fp is
> not set on the Isolate for Fast-C-Calls because we don't build an exit
> frame.
>
> This change makes stack samples that occur within 'Fast-C-Calls'
> iterable, meaning we can properly attribute ticks within the JS caller.
>
> Fast-C-Calls can't call back into JS code, so we can only ever have one
> such call on the stack at a time, allowing us to store the FP on the
> isolate rather than the stack.
>
> TBR=v8-mips-ports@googlegroups.com
>
> Bug: v8:8464, v8:7202
> Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
> Reviewed-on: https://chromium-review.googlesource.com/c/1340241
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
> Reviewed-by: Alexei Filippov <alph@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57896}
TBR=v8-mips-ports@googlegroups.comTBR=jgruber@chromium.org
Bug: v8:8464, v8:7202
Change-Id: I5f37ded4ea572e8e9890ba186aa3d74a0dfc1274
Reviewed-on: https://chromium-review.googlesource.com/c/1354042
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57912}
These two tests fail if the memory used by builtins increases too much.
They aren't intended to monitor the memory used by builtins, so these
failures are spurious.
Bug: v8:8521
Change-Id: I67e61abe30aaf69aeb3e6a2c885795061a318851
Reviewed-on: https://chromium-review.googlesource.com/c/1354041
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57911}
This constant is unused, and should never be used, since name sections
are encoded as an unknown section with the special name "name".
R=ahaas@chromium.org
Change-Id: I2fa1a21506dbe30033aecb3c1bf9ad84b6b872bc
Reviewed-on: https://chromium-review.googlesource.com/c/1352305
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57905}
This reverts commit d5f4a33eb8.
Reason for revert: Seems to cause a no snapshot build failure - https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20nosnap%20-%20debug/21967
Original change's description:
> [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
>
> Before fast C calls, store the current FP and PC on the isolate. When
> iterating frames in SafeStackFrameIterator, check if these fields are
> set and start iterating at the calling frame's FP instead of the current
> FP, which will be in C++ code. We need to do this because c_entry_fp is
> not set on the Isolate for Fast-C-Calls because we don't build an exit
> frame.
>
> This change makes stack samples that occur within 'Fast-C-Calls'
> iterable, meaning we can properly attribute ticks within the JS caller.
>
> Fast-C-Calls can't call back into JS code, so we can only ever have one
> such call on the stack at a time, allowing us to store the FP on the
> isolate rather than the stack.
>
> TBR=v8-mips-ports@googlegroups.com
>
> Bug: v8:8464, v8:7202
> Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
> Reviewed-on: https://chromium-review.googlesource.com/c/1340241
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
> Reviewed-by: Alexei Filippov <alph@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57896}
TBR=alph@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,martyn.capewell@arm.com,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,ibogosavljevic@wavecomp.com
Change-Id: I85f846e57b6fa845e7770c616435cebffdb2a245
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8464, v8:7202
Reviewed-on: https://chromium-review.googlesource.com/c/1352302
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57899}
The test was flaky because it assumed that AllocatedAssemblerBuffer
would eventually return an address within near-call range. Rarely, this
did not happen (within the retry limit), and so the test would crash.
This fix allocates a single, kMaxWasmCodeMemory-sized buffer for the
test, and generates call sequences within that buffer.
BUG=v8:8245
Change-Id: I4b44d897c6cbda15a18ab992fa57805de3b2db29
Reviewed-on: https://chromium-review.googlesource.com/c/1347484
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jacob Bramley <jacob.bramley@arm.com>
Cr-Commit-Position: refs/heads/master@{#57898}
Before fast C calls, store the current FP and PC on the isolate. When
iterating frames in SafeStackFrameIterator, check if these fields are
set and start iterating at the calling frame's FP instead of the current
FP, which will be in C++ code. We need to do this because c_entry_fp is
not set on the Isolate for Fast-C-Calls because we don't build an exit
frame.
This change makes stack samples that occur within 'Fast-C-Calls'
iterable, meaning we can properly attribute ticks within the JS caller.
Fast-C-Calls can't call back into JS code, so we can only ever have one
such call on the stack at a time, allowing us to store the FP on the
isolate rather than the stack.
TBR=v8-mips-ports@googlegroups.com
Bug: v8:8464, v8:7202
Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
Reviewed-on: https://chromium-review.googlesource.com/c/1340241
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57896}
The MemoryInitImmediate and TableInitImmediate read a Memory/Table
index, followed by a segment index. If reading the first index fails, we
need to stop reading, or the decoder will read past the end.
Bug: chromium:907324
Change-Id: I3eb46c08d03e3b2e44ed4081d307b32c799abcec
Reviewed-on: https://chromium-review.googlesource.com/c/1351502
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57889}
See usage in the js-api tests; previously it would have thrown without
executing any tests. Now, it can be used to generate trapping functions.
Bug: v8:8319
Change-Id: Ia1643d8f337a10ea86c1e700c7702ed7d3ed0c97
Reviewed-on: https://chromium-review.googlesource.com/c/1352298
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57885}
This avoids leaving the heap in an invalid state if a GC occurs during
population of the cloned property array, as is done in other IC
builtins.
BUG=chromium:904167, v8:7611
R=jkummerow@chromium.org, ishell@chromium.org
Change-Id: I0350ed2d65b72e299f7109b7d5aa86331f60e940
Reviewed-on: https://chromium-review.googlesource.com/c/1350282
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57879}
Only log incrementally deserialized maps with --trace-maps instead of
iterating the whole heap and print all existing maps on every partial
deserialization for new contexts. This should greatly improve
performance of --trace-maps on websites with many iframes.
- Add helpers to share code: LogNewObjectEvents, LogScriptEvents,
LogNewMapEvents
- Link AllocationSites before any GC
Change-Id: I5322421a83e057518f871540691511c80bc7786a
Reviewed-on: https://chromium-review.googlesource.com/c/1342029
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57874}
Unfortunately the previous strategy was slower but more memory efficient. For now simply revert.
Revert "[zone] Use 32kb instead of 1MB as high zone page size"
Revert "[zone] Get rid of the Zone's segment pool"
Revert "[zone] Further simplify zone expansion, use single default page size"
Bug: chromium:908359
Change-Id: I649542e7e61eef0c14a26ffd21039e8340ab4d04
Reviewed-on: https://chromium-review.googlesource.com/c/1351027
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57872}
This unifies the order of i-cache flushing and permission changing
throughout V8. According to cctest/test-icache flushing after the
permission change is not robust on some ARM32 and ARM64 devices.
There have been observed failures of {TestFlushICacheOfExecutable} on
some devices. So far there haven't been any observed failures of the
corresponding {TestFlushICacheOfWritable} test.
Also the order of flushing before the permission change is the natural
order in which the GC currently performs operations. Until we see
concrete data substantiating the opposite, the following is the
supported and intended order throughout V8:
exec -> perm(RW) -> patch -> flush -> perm(RX) -> exec
This CL tries to establish said order throughout the codebase.
R=ulan@chromium.org
TEST=cctest/test-icache
BUG=v8:8507,chromium:845877
Change-Id: Ic945082e643aa2d142d222a7913a99816aff4644
Reviewed-on: https://chromium-review.googlesource.com/c/1351025
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57869}
Pushing unresolved variables at the front was an optimization for the case
where we didn't have an end pointer. That forces us to do an O(<new elements>)
walk to rescope variables. The implementation was more generic and even did
O(<all elements>). Now that we have an end pointer we can simply push at the
end and MoveTail which is O(1).
Change-Id: I65cd5752b432223d95cd529452a064d8dcc812e1
Reviewed-on: https://chromium-review.googlesource.com/c/1351010
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57868}
This reverts commit 4644b32e02.
Reason for revert: Link errors on win64: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64%20-%20debug/25950
Original change's description:
> [wasm] Add more unit tests for trap handler
>
> The unittests test if the trap handler only handles those traps it
> is supposed to handle:
> * Only handle traps when the thread-in-wasm flag is set.
> * Only handle traps of the right type, i.e. memory access violations.
> * Only handle traps at recorded instructions.
>
> The tests also test the consistency of the thread-in-wasm flag. I made
> one change in the trap handler where that consistency could be
> violated.
>
> All tests are executed with the default trap handler provided by V8,
> and with the trap handler callback installed in a test signal/exception
> handler.
>
> Change-Id: I03904bb6effd2e8694d3f4d1fbf62bc38002646e
> Reviewed-on: https://chromium-review.googlesource.com/c/1340246
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57858}
TBR=mstarzinger@chromium.org,ahaas@chromium.org,mark@chromium.org
Change-Id: Iac2f20c73744226885ea1810813863a21c5faf8c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/1351021
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57861}
The {setTableLength} method is redundant and has a single user. Remove
it, use {setTableBounds} instead.
Drive-by: Add default to the table max, to document that this can
actually be {undefined}, in which case the table has no maximum.
R=binji@chromium.org
Bug: v8:8238
Change-Id: I0d7a2f4d49d083f7adadbb4b6cd4933bcb1dc174
Reviewed-on: https://chromium-review.googlesource.com/c/1350126
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57860}
The unittests test if the trap handler only handles those traps it
is supposed to handle:
* Only handle traps when the thread-in-wasm flag is set.
* Only handle traps of the right type, i.e. memory access violations.
* Only handle traps at recorded instructions.
The tests also test the consistency of the thread-in-wasm flag. I made
one change in the trap handler where that consistency could be
violated.
All tests are executed with the default trap handler provided by V8,
and with the trap handler callback installed in a test signal/exception
handler.
Change-Id: I03904bb6effd2e8694d3f4d1fbf62bc38002646e
Reviewed-on: https://chromium-review.googlesource.com/c/1340246
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57858}
This CL makes it easier to organize the Context classes hierarchy and
simplifies Context class definition.
Bug: v8:8238
Change-Id: I65b8255daf255649c597dc195edf436d9471e3ea
Reviewed-on: https://chromium-review.googlesource.com/c/1350109
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57848}
Add a path into embedder tracing on allocation. This is safe as as Blink
is not allowed to call into V8 during object construction.
This is a reland of caed2cc033.
Also relands the cleanups of ce02d86bf2.
Bug: chromium:843903
Change-Id: Ic89792fe68337c540a1a93629aee2e92b8774ab2
Reviewed-on: https://chromium-review.googlesource.com/c/1350992
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57847}
This patch gives DescriptorArray its own visitor id and its
own layout that is independent from the layout of WeakFixedArray.
This allows us to use raw 16-bit integers for keeping track of
the number of descriptors (total, non-slack, and marked).
As a side-effect, we save one word per descriptor array on 64-bit.
v8:8486
Change-Id: If8389dde446319e5b3491abc948b52539dba235c
Reviewed-on: https://chromium-review.googlesource.com/c/1349245
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57845}
For indirect calls, we need to set up the tables correctly. This CL
adds this to the test case generation logic.
R=ahaas@chromium.org
Change-Id: I18a5a8e0659c46daec00d46d02fe50d5d94638d6
Reviewed-on: https://chromium-review.googlesource.com/c/1349985
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57838}
Indirect calls rely on fixed signature indexes. Thus make test case
generation output the signatures exactly like they appear in the module.
R=ahaas@chromium.org
Change-Id: I80b088024da759ec87695363aeefb28685e1d704
Reviewed-on: https://chromium-review.googlesource.com/c/1350831
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57837}
This CL adds new Wasm import call kinds that correspond to various
math functions that can be imported from JavaScript, such as trigonometry.
Instead of calling a special import wrapper that converts arguments
to tagged values by boxing, we can now generate calls to little WASM
stubs that contain a single WASM bytecode each.
R=mstarzinger@chromium.org
BUG=v8:8423
Change-Id: I59b1be2dd36d190a8b6c98b88c86cecc0ca7f4a2
Reviewed-on: https://chromium-review.googlesource.com/c/1349279
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57835}
We cannot assign a meaningful type to Promise#catch() or
Promise#finally(), since they both return whatever the invocation of
'then' on the receiver returns, and that is monkeypatchable by arbitrary
user JavaScript.
Bug: chromium:908309, v8:7253
Change-Id: Ib15f81c366938a1b1f10be6c6af85c1f3374b898
Reviewed-on: https://chromium-review.googlesource.com/c/1350789
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57828}
It's been failing for a while, and looks like we reach some arbitrary
heap limit, triggering an early OOM before the debugger hook is set.
Bug: v8:8494
Change-Id: I472dc8955ba2f0eb018ac6e7ca83e4beaaefc318
Reviewed-on: https://chromium-review.googlesource.com/c/1350830
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57820}
- Remove heap-inl.h includes from places where it looked unnecessary. (This is a
non-scientific approach, because it's probably pulled in indirectly anyway.)
- Annotate places which include heap-inl.h because they need heap/ internals.
- ACCESSORS legitimately needs heap-inl.h because of Heap::FromWritableHeapObject.
- Add includes to heap/heap-write-barrier(-inl).h
- A bunch of IWYU fixes discovered when working on this CL (includes which were
missing because heap-inl.h pulls them in indirectly).
BUG=v8:7490,v8:8238,v8:8499
Change-Id: I00f9a74d430f13d7c080dca77a92b03bcca7ef96
Reviewed-on: https://chromium-review.googlesource.com/c/1349241
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57814}
to the new design.
Bug: v8:3770
Change-Id: I3cd0a66eefefedc98a641494302fc79d897a153a
Reviewed-on: https://chromium-review.googlesource.com/c/1345910
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57801}
This is a reland of a5336471f2
Original change's description:
> [builtins] Implement Object.fromEntries
>
> Adds the Object.fromEntries() method behind
> --harmony-object-from-entries.
>
> > Includes an initial implementation of the new experimental builtin
> Object.fromEntries implemented by Daniel Clifford, and
> has been modified by Caitlin Potter to support a fast case to skip
> the iterator protocol when it can be done unobservably in common cases.
>
> There are some incidental changes: A number of CSA macros have been
> updated to use TNodes, and some Context arguments have been
> re-arranged to be implicit in Torque. >
>
> There are also a number of mjsunit tests written mirroring and
> expanding on the test262 tests.
>
> BUG=v8:8021
>
> Change-Id: I1c12bee8a2f98c6297b77d5d723910a5e3b630cc
> Co-authored-by: Daniel Clifford <danno@chromium.org>
> Co-authored-by: Caitlin Potter <caitp@igalia.com>
> Reviewed-on: https://chromium-review.googlesource.com/c/1337585
> Commit-Queue: Daniel Clifford <danno@chromium.org>
> Reviewed-by: Daniel Clifford <danno@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57667}
Bug: v8:8021
Change-Id: I706e2d87bfc2f688e833c1b7d40ca82f5d80f5a2
Reviewed-on: https://chromium-review.googlesource.com/c/1346630
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#57798}
Provide processing scope that makes it impossible to maintain locally
cached wrappers that could get invalidated in Blink and yield in
crashers.
Bug: chromium:843903, v8:8238
Change-Id: I7ba1905f6c77a97bcc61ac42f921dcac4772471f
Reviewed-on: https://chromium-review.googlesource.com/c/1349276
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57795}
Rather check expressions used as patterns directly. Check parentheses by
tagging parenthesized expressions as parenthesized.
This allows us to drop UnexpectedPatternToken and makes it clear why a specific
token is unexpected (because it's invalid in a binding pattern).
This also more uniformly restores messages like "Invalid destructuring
assignment target".
Change-Id: Idd98e9116c85de4c2304cf1fef1baa097b67149d
Reviewed-on: https://chromium-review.googlesource.com/c/1349572
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57792}
+ fixing other files which were depending on context-inl.h pulling in the
missing includes.
BUG=v8:7490,v8:8238
Change-Id: I90d37599bdfb69ac8fd7e62b8fb78d9d77c77234
Reviewed-on: https://chromium-review.googlesource.com/c/1349277
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57775}
This changes the split from AssignmentPattern and BindingPattern to Pattern and
BindingPattern. Pattern collects all errors that are invalid in both assignment
and binding pattern contexts. Binding pattern additionally collects errors for
binding pattern contexts (property access isn't a valid target). The
distinction is piggybacked on to distinguish assignment vs binding pattern
errors since binding pattern verification will first throw the binding pattern
error.
Since we don't throw pattern error as binding pattern as well, this can mean
that a later binding pattern syntax error will show up before an early pattern
error. Since that just changes the message to another syntax violation, I think
that's fine.
Change-Id: Ib6a22c8d11c49eacc6667ae8ee5e98bababadd43
Reviewed-on: https://chromium-review.googlesource.com/c/1349273
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57774}
This API allows the embedder to provide a stack and PC, FP and
SP registers. V8 will then attempt to unwind the stack to the C++ frame
that called into JS. This API is signal-safe, meaning it does not call
any signal-unsafe OS functions or read/write any V8 state.
Bug: v8:8116
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I7e3e73753b711737020b6a5f11946096658afa6f
Reviewed-on: https://chromium-review.googlesource.com/c/1186724
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57749}
Port fed7bb501e
Original Commit Message:
This test cases ensures that it is possible to maintain a coherent
instruction cache by using {Assembler::FlushICache} in any order with
respect to changing page permissions via {SetPermissions}.
R=mstarzinger@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:6792
LOG=N
Change-Id: I23d5d0828dcbdd527aaa8708fa726a7cb5cbedfe
Reviewed-on: https://chromium-review.googlesource.com/c/1347511
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#57745}
Instead, simply track it as a valid binding pattern. To do this in the case of
parenthesized formals, we delay throwing the binding pattern error for
parenthesized (and async "calls") until we know it's not an arrow function head
by itself.
This guarantees that if an arrow head is a valid binding pattern, it's either a
valid parenthesized head or a valid identifier, or invalid pattern ("array" or
"object" literal style). We can detect the latter case by checking that the
current token is not a RPAREN and the expression isn't an identifier.
(Alternatively we could check that the curren token is RBRACE or RBRACK...)
Bug: chromium:907575
Change-Id: Ie40cc3235d3188f2620b6c089a0f49d93604dda6
Reviewed-on: https://chromium-review.googlesource.com/c/1348078
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57743}
Adds a new field rare_data of type FunctionTemplateRareData to
FunctionTemplateInfo and moves 8 others which are unset on 90% of
FunctionTemplateInfo objects to this field.
Getters like prototype_template() are changed to GetPrototypeTemplate()
to indicate they're not trivial. The setters are replaced with static
methods (e.g. SetPrototypeTemplate) that take an Isolate and the
template object, since they can now perform allocation.
Bug: v8:8478
Change-Id: If72b132ade4ca4a3f803f913761c9caddc0e9dd6
Reviewed-on: https://chromium-review.googlesource.com/c/1342519
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57725}
Many tests were already skipped in debug mode, but they kept running on CQ
which sets dcheck_always_on, probably equally slow.
Some other tests are marked as slow based on a recent run of the arm64 sim
trybot.
NOTRY=true
Bug: v8:7783
Change-Id: Ic022518edfa112ea6d228ae9a68653c99651dbb4
Reviewed-on: https://chromium-review.googlesource.com/c/1347479
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57724}
Previosly, LoadArrayElement assumed that the array is a FixedArray.
The PropertyArray and WeakFixedArray pretended to be a FixedArray and
had static asserts about length offsets.
This patch make LoadArrayElement generic and uses a new LoadArrayLength
function to fetch the length of the array without hard-coding the length
offset.
Bug: v8:8486
Change-Id: Ib27132bf3fcecc135ad632c4227c57ca0a05036f
Reviewed-on: https://chromium-review.googlesource.com/c/1346498
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57723}
Remove PrintableInstructionSequence and friends, just overload
operator<< directly for the respective types.
R=herhut@chromium.org
Bug: v8:8238
Change-Id: I67713978ab06f7ec5309e52b4090256480f362b1
Reviewed-on: https://chromium-review.googlesource.com/c/1346113
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Stephan Herhut <herhut@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57722}
This CL moves the two remaining IC stubs to builtins, generating a
dedicated builtin for each KeyedAccessStoreMode variant.
Bug: v8:7777
Change-Id: I540b3c3437adb94094771a19713e71ec8a349553
Reviewed-on: https://chromium-review.googlesource.com/c/1346095
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57719}
This CL moves optimization capabilities from typed lowering to typed
optimization. In particular, this allows retyping of Speculative to
number optimizations depending on their input types. This can save type
checks if we know that inputs are already in SafeIntegerRange and uses
are truncating to 32bit integers.
This change recovers the performance lost to 31bit Smis on
Octane/crypto on x64:
32bit nosmis avg 30,984.84 stddev 180.52
31bit smis (w/o patch) avg 29,438.52 stddev 120.30 -4.99%
31bit smis avg 31,274.52 stddev 176.26 +0.93% +6.24%
Change-Id: I86d6e37305262336f4f7bd46aac0d2cbca11e8c1
Bug: v8:8344
Reviewed-on: https://chromium-review.googlesource.com/c/1323729
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57717}
This is a reland of 6ec90ecee2
Original change's description:
> Reland "Create a fast path to get migration target when updating map"
>
> This is a reland of c285380ca8
>
> Original change's description:
> > Create a fast path to get migration target when updating map
> >
> > During map updating, store the pointer to new map in the
> > raw_transitions slot of the old map that is deprecated from map
> > transition tree. Thus, we can get the migration target directly
> > instead of TryReplayPropertyTransitions when updating map.
> >
> > This can improve Speedometer2.0 Elm-TodoMVC case by ~5% on ATOM
> > Chromebook and ~9% on big-core Ubuntu.
> >
> > Change-Id: I56f9ce5183bbdd567b964890f623ef0ceed9b7db
> > Reviewed-on: https://chromium-review.googlesource.com/1233433
> > Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
> > Reviewed-by: Igor Sheludko <ishell@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#56303}
>
> Change-Id: Idf0b7716b92a6a15bfe58721c2c34dbd02b31137
> Reviewed-on: https://chromium-review.googlesource.com/c/1270261
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
> Cr-Commit-Position: refs/heads/master@{#56588}
Change-Id: Iad23455f66c83340430370be6670bac493c638a1
Reviewed-on: https://chromium-review.googlesource.com/c/1309305
Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57705}
Moves allocation of the WasmModuleObject for asm.js code out of SyncCompileTranslatedAsmJS
since that is called when we are compiling the native context independent SharedFunctionInfo
and the WasmModuleObject requires a native context. Instead save the members required to
create the object in the AsmWasmData and create it during module instantiation. Note:
since the Wasm module is an implementation detail for asm_wasm code and isn't exposed,
this doeesn't have semantic change for asm.js code.
As part of this change, the AsmWasmData is changed from a FixedArray to a dedicated
struct. Some logic is also moved from module-compiler to wasm-engine to make the
seperation between Wasm SyncCompile and AsmJS SyncCompile more clear.
BUG=chromium:900535,v8:8395
Change-Id: Ia48469c095b0688f210aa86e7430c9ab4ea4b26b
Reviewed-on: https://chromium-review.googlesource.com/c/1345509
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57704}
Types such as "function" have a ValueMirror that does not override
"buildObjectPreview()". This CL updates clients to check that the
preview was actually built after call it.
Bug: chromium:907400
Change-Id: Id569c98363d47b259a40790b596efedb3d14abc2
Reviewed-on: https://chromium-review.googlesource.com/c/1347067
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Erik Luo <luoe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57703}
Load elimination is running together with to dead code elimination, the
latter of which might eliminate allocations (in particular FinishRegion
nodes). These are treated as alias nodes by load elimination, and load
elimination does not immediatelly learn that a node has been disconnected.
This causes load elimination to access the inputs of dead code eliminated
nodes while resolving renames, which causes nullptr dereferences.
This CL modifies load elimination to not resolve to a nullptr alias but
simply stop before that.
Change-Id: If4cef061c7c0e25f353727c9e27f790439b0beb5
Bug: chromium:906406
Reviewed-on: https://chromium-review.googlesource.com/c/1346491
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57688}
an abstraction that hides the details about how embedder data fields are
encoded in EmbedderDataArrays and JSObjects.
Bug: v8:7703
Change-Id: Ic9f6d9511bec557c6671aa6488b9545e353f968c
Reviewed-on: https://chromium-review.googlesource.com/c/1344155
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57679}
This reverts commit a5336471f2.
Reason for revert: Fails nosnap debug tests: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20nosnap%20-%20debug/21838
Original change's description:
> [builtins] Implement Object.fromEntries
>
> Adds the Object.fromEntries() method behind
> --harmony-object-from-entries.
>
> > Includes an initial implementation of the new experimental builtin
> Object.fromEntries implemented by Daniel Clifford, and
> has been modified by Caitlin Potter to support a fast case to skip
> the iterator protocol when it can be done unobservably in common cases.
>
> There are some incidental changes: A number of CSA macros have been
> updated to use TNodes, and some Context arguments have been
> re-arranged to be implicit in Torque. >
>
> There are also a number of mjsunit tests written mirroring and
> expanding on the test262 tests.
>
> BUG=v8:8021
>
> Change-Id: I1c12bee8a2f98c6297b77d5d723910a5e3b630cc
> Co-authored-by: Daniel Clifford <danno@chromium.org>
> Co-authored-by: Caitlin Potter <caitp@igalia.com>
> Reviewed-on: https://chromium-review.googlesource.com/c/1337585
> Commit-Queue: Daniel Clifford <danno@chromium.org>
> Reviewed-by: Daniel Clifford <danno@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57667}
TBR=danno@chromium.org,caitp@igalia.com,tebbi@chromium.org
Change-Id: Id0cd8b16131f151a42dffbaca7e59ab17c68ab23
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8021
Reviewed-on: https://chromium-review.googlesource.com/c/1346116
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57677}
This extracts the parts of the TypedSlotSet that are used only
sequentially into a separate class called TypedSlots.
The new class will be used in the concurrent marker to keep track of
typed slots locally and then to merge them to the main remembered set
during finalization of marking.
The patch also cleans up atomics in the Iterate and ClearInvalidSlots
methods that can run concurrently to each other.
Bug:v8:8459
Change-Id: Id7a63041f7b99218381e5e9e1999210cab9c4369
Reviewed-on: https://chromium-review.googlesource.com/c/1340247
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57673}
Register names are static, so we do not need to access them via
RegisterConfiguration. This saves a lot of RegisterConfiguration
object creations.
R=mstarzinger@chromium.org
Bug: v8:8238
Change-Id: I295ad4d4b13fe948c70490687b7e3e9b48e70af9
Reviewed-on: https://chromium-review.googlesource.com/c/1342517
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57668}
Adds the Object.fromEntries() method behind
--harmony-object-from-entries.
Includes an initial implementation of the new experimental builtin
Object.fromEntries implemented by Daniel Clifford, and
has been modified by Caitlin Potter to support a fast case to skip
the iterator protocol when it can be done unobservably in common cases.
There are some incidental changes: A number of CSA macros have been
updated to use TNodes, and some Context arguments have been
re-arranged to be implicit in Torque.
There are also a number of mjsunit tests written mirroring and
expanding on the test262 tests.
BUG=v8:8021
Change-Id: I1c12bee8a2f98c6297b77d5d723910a5e3b630cc
Co-authored-by: Daniel Clifford <danno@chromium.org>
Co-authored-by: Caitlin Potter <caitp@igalia.com>
Reviewed-on: https://chromium-review.googlesource.com/c/1337585
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57667}
This is a reland of 585b4eef6a without
any changes.
Original change's description:
> [turbofan] Improve NumberMultiply typing rule.
>
> The NumberMultiply typing rule gave up in the presence of NaN inputs,
> but we can still infer useful ranges here and just union the result
> of that with the NaN propagation (similar for MinusZero propagation).
> This way we can still makes sense of these ranges at the uses.
>
> Bug: v8:8015
> Change-Id: Ic4c5e8edc6c68776ff3baca9628ad7de0f8e2a92
> Reviewed-on: https://chromium-review.googlesource.com/c/1261143
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56539}
Tbr: bmeurer@chromium.org
Bug: v8:8015
Change-Id: I32e5c2f439a1186891ca3393ee53a2a766585839
Reviewed-on: https://chromium-review.googlesource.com/c/1345993
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57664}
When ASAN is enabled, the previous implementation of
Isolate::GetIncumbentContext didn't work well due to mixture of fake
and real stack frames.
This patch converts an address in the fake stack frame to an address
in the real stack frame so that we can compare two addresses.
Bug: chromium:888867, chromium:866610
Change-Id: Iccf570b8555f2fbdc737b12894a2784ffdb31602
Reviewed-on: https://chromium-review.googlesource.com/c/1343709
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Yuki Shiino <yukishiino@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57662}
Instead of returning 0xDEADBEEF, return a struct with proper
information. Otherwise a function returning 0xDEADBEEF would be
misidentified as trapping in the interpreter.
R=ahaas@chromium.org
Bug: chromium:906997
Change-Id: I92fc3a9972d76d2f8a5b313bf6be6eb027cfc1e9
Reviewed-on: https://chromium-review.googlesource.com/c/1344111
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57658}
This test cases ensures that it is possible to maintain a coherent
instruction cache by using {Assembler::FlushICache} in any order with
respect to changing page permissions via {SetPermissions}.
R=ulan@chromium.org
TEST=cctest/test-icache
BUG=v8:6792
Change-Id: I1778bbbe94b40856d9732a9990a931b5a956a439
Reviewed-on: https://chromium-review.googlesource.com/c/1344113
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57651}
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
Our toolchain fails to link unittests without this change.
Change-Id: I48cc61f45fe5d533ed207f987371893caf54a919
Reviewed-on: https://chromium-review.googlesource.com/c/1340293
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ivica Bogosavljevic <ibogosavljevic@wavecomp.com>
Cr-Commit-Position: refs/heads/master@{#57634}
Previously the simplified operation `Number.min(x,y)` would lower to
`Select(Float64LessThan(x, y), x, y)` which would yield `y` when both
`x` and `y` are zeros, specifically when `x` was -0 and `y` was +0.
For `NumberMin` we need to use `Float64LessThanOrEqual` since we
generally allow -0 on the left hand side (in SimplifiedLowering).
Bug: chromium:906870
Change-Id: I25ae8fb19608b77c90ed130e69d9d9fa93fcea9d
Reviewed-on: https://chromium-review.googlesource.com/c/1342920
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57633}
This change ensures that we do not try to check the conversion of a floating
point constant, but insert the floating point constant instead.
Change-Id: I1c65e3a69acaea2ff805ba10317f64c0ac0ba098
Reviewed-on: https://chromium-review.googlesource.com/c/1340257
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57630}
These instructions aren't implemented yet in TF or in Liftoff, but they
are properly decoded.
The table instructions (i.e. `table.{init,drop,copy}`) are validated,
since the table and element sections occur before the code section. The
memory instructions (i.e. `memory.{init,drop,copy,fill}`) are not
validated because the data section occurs after the code section, so it
can't be verified in one pass (without throwing a validation error
later).
There is currently a discussion about whether to add a new section
(similar to `func`) that predefines the number of expected data
segments. If we add this, then we can validate in one pass. For now,
we'll leave it unimplemented.
Bug: v8:7747
Change-Id: I839edf51721105a47a1fa8dd5e5e1bd855e72447
Reviewed-on: https://chromium-review.googlesource.com/c/1339241
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57622}
Do less work in MultipleProfilers. Reduces runtime from ~8 mins to ~40
seconds.
Bug: v8:8474
Change-Id: I72b3266941ce40c8d064deaf00fb06f8d9fa8a70
Reviewed-on: https://chromium-review.googlesource.com/c/1341956
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57613}
This reverts commit 585b4eef6a.
Reason for revert: Speculative, crbug 906567.
Original change's description:
> [turbofan] Improve NumberMultiply typing rule.
>
> The NumberMultiply typing rule gave up in the presence of NaN inputs,
> but we can still infer useful ranges here and just union the result
> of that with the NaN propagation (similar for MinusZero propagation).
> This way we can still makes sense of these ranges at the uses.
>
> Bug: v8:8015
> Change-Id: Ic4c5e8edc6c68776ff3baca9628ad7de0f8e2a92
> Reviewed-on: https://chromium-review.googlesource.com/c/1261143
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56539}
TBR=sigurds@chromium.org,bmeurer@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8015
Change-Id: I3c652bafbbc0e5d1ad4ff288264fd4f4cbf71330
Reviewed-on: https://chromium-review.googlesource.com/c/1340253
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57602}
Fail IsInvalid check if the property cell has been invalidated.
Bug: chromium:905555
Change-Id: Ia0712b97bd6ba628936b74b3893ddb1c229ee686
Reviewed-on: https://chromium-review.googlesource.com/c/1339863
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57597}
Both regress-8432 and regress-8413 pass with the latest ICU
roll to 407b393.
TBR=ftang@chromium.org,gsathya@chromium.org,machenbach@chromium.org
Bug: v8:8432,v8:8414
Change-Id: I56f3d88c1f90021ad51062bc5f26a9e88877f954
Reviewed-on: https://chromium-review.googlesource.com/c/1341455
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Jungshik Shin <jshin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57590}
This patch allows the deoptimizer to keep embedded pointers intact.
Previously, the deoptimizer had to clear embedded pointers because
the mark-compactor relied on the Code::marked_for_deoptimization flag
to indicate whether the embedder pointers were cleared or not.
This patch adds a new flag called Code::embedded_objects_cleared()
and thus can correctly clear dead weak objects in deoptimized code.
Bug: v8:8459
Change-Id: I6eb6ff3aa2182bc41730e0a249965f8d8c0525ce
Reviewed-on: https://chromium-review.googlesource.com/c/1335943
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57584}
The platform specific macro assembler headers can not be included
directly. They require symbols declared in macro-assembler.h.
We also cannot include macro-assembler.h from the platform specific
headers, because that would form a cycle, and the include in
macro-assembler.h would be skipped, which then also fails.
This CL documents and enforces this unfortunate situation.
This helps with further iwyu cleanups.
Note that current code which includes the platform specific headers
only works because we transitively included macro-assembler.h already
before.
R=mstarzinger@chromium.org
Bug: v8:8238, v8:7490
Change-Id: I2dc65ad950400941406e1f2f8969d0d15f524bf8
Reviewed-on: https://chromium-review.googlesource.com/c/1340240
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57578}
GC needs to be able to read a bigint's length while the main thread may
change the length and the sign (bigints are intentionally mutable as
long as they haven't escaped to user code). Since both values are stored
in the same bitfield, we need to make these accesses atomic.
Also change right-trimming to not insert a filler when the object is
in large object space (it makes no sense there).
Bug: v8:8440
Change-Id: I72a1b6f1eda54566d3cfad554dda1a98ddd61975
Reviewed-on: https://chromium-review.googlesource.com/c/1337737
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57576}
For short inputs (<= size of the type we want to generate), we fell back
to just generating constants. This CL changes that to only fall back to
constants once a single byte remains, and adds options to use constants
already before that.
R=ahaas@chromium.org
Bug: v8:894307
Change-Id: Ic4bf05d06090f52b67de2b322a9d5dcab6bbbe39
Reviewed-on: https://chromium-review.googlesource.com/c/1337739
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57573}
This CL implements an assembly order optimization that moves blocks
that end a loop with an unconditional backedge to the beginning of
the loop, saving a branch.
R=jarin@chromium.org,mstarzinger@chromium.org
BUG=v8:8423
Change-Id: I8a5d25f5472d71227af0f623277ea8d0a8d69867
Reviewed-on: https://chromium-review.googlesource.com/c/1335944
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57572}
This adds a new C++ API method
```cpp
Local<Object> Object::New(
Isolate* isolate,
Local<Value> prototype_or_null,
Local<Name>* keys,
Local<Value>* values,
size_t size);
```
which is similar to the `Object.create()` builtin exposed by JavaScript.
This new API is supposed to be used by the `http2` (in Node.js) to speed
up the creation of the HTTP header object.
Bug: v8:8422
Change-Id: I9910e88de0af2cbd8ce8a1d6cb6caa9451fb8cb4
Design-Document: http://bit.ly/v8-fast-object-create-cpp
Reviewed-on: https://chromium-review.googlesource.com/c/1337569
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57570}
This marks the InterpreterEntryTrampoline as isolate-independent. With
this change, all builtins are now embedded.
Slight changes were needed to how we deopt into the trampoline. We now
store the entry address within the Interpreter class instead of
embedding the builtin code target.
Bug: v8:7777
Change-Id: If781bf6f06cb2efbab1369ece757f04c343a1b38
Reviewed-on: https://chromium-review.googlesource.com/c/1337734
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57563}
With just five cache registers, Liftoff can run out of memory on a
64bit shift. This CL solves this by using a parallel register move and
pinning less registers.
R=ahaas@chromium.org
Bug: chromium:894307
Change-Id: I91ed0fee00ceb452841e5d1bb10905be6702dcce
Reviewed-on: https://chromium-review.googlesource.com/c/1337580
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57552}
This test is only flaky because the js code being profiled causes a
'fast-c-call' which is a call from JS to C without an exit frame.
The profiler stumbles on these and reads the stack of C++ frames when
it shouldn't, causing ASAN errors. This is not actually related to
the multiple isolates, so I'm changing the test to profile different
JS code that does not cause these types of calls. There is already a
test for fast-c-calls - NativeFrameStackTrace (which currently fails).
Bug: v8:8464
Change-Id: I32818f0894e5680cf5a39779a2779eda36dfe9f1
Reviewed-on: https://chromium-review.googlesource.com/c/1337571
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57547}
This is a reland of 0b13f0f517
Original change's description:
> [snapshot] Emit the embedded blob as assembly instead of inline assembly
>
> The motivation behind this is that MSVC doesn't support inline assembly
> on x64. Emitting the embedded blob as a plain assembly file will give us
> MSVC support (and possibly faster compilation times as a side-effect).
>
> Bug: v8:6666,v8:8349
> Change-Id: I2e6cf072faa9ef406fe721a05b63912c655546c2
> Reviewed-on: https://chromium-review.googlesource.com/c/1329205
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57524}
Tbr: yangguo@chromium.org,mvstanton@chromium.org
Bug: v8:6666, v8:8349
Change-Id: Ib35696b60a9cd01bc2edf459c8e8d84716e3438d
Reviewed-on: https://chromium-review.googlesource.com/c/1337733
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57546}
This is a reland of bf2f0a0227
Original change's description:
> [builtins] Support embedded builtins in nosnapshot builds
>
> This CL adds support for embedded builtins in nosnap builds by creating
> and setting an 'embedded blob' after builtin generation. Unlike
> snapshot builds, the blob is not embedded into the .text section but
> located on the C++ heap.
>
> This makes nosnap builds more consistent with mksnapshot, and allows us
> to simplify there and in serializer cctests.
>
> Complications arise from the different workflows we need to support:
>
> 1. the standard mksnapshot build process,
> 2. nosnap builds (which reuse the blob created by the first Isolate),
> 2. and tests with various complicated serialization workflows.
>
> To cover all of these cases, this CL introduces two knobs to twiddle:
>
> 1. A 'sticky' embedded blob which overrides compiled-in default
> embedded blobs at Isolate setup.
> 2. The blob lifecycle can be managed manually or through refcounting.
>
> These are described in more detail in isolate.cc.
>
> Tbr: ulan@chromium.org
> Bug: v8:6666, v8:8350
> Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d
> Reviewed-on: https://chromium-review.googlesource.com/c/1310195
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57523}
Tbr: ulan@chromium.org,yangguo@chromium.org
Bug: v8:6666, v8:8350
Change-Id: I13b523c9e7406b39a3cd28465c06f17f1744a738
Reviewed-on: https://chromium-review.googlesource.com/c/1337578
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57540}
We often need to create a {Vector} view of data owned by a container
like {std::vector}. The canonical way to do this is this:
Vector<T>{vec.data(), vec.size()}
This pattern is repeating information which can be deduced
automatically, like the type T.
This CL introduces a {VectorOf} helper which can construct a {Vector}
for any container providing a {data()} and {size()} accessor, and uses
it to replace the pattern above.
R=ishell@chromium.org
Bug: v8:8238
Change-Id: Ib3a11662acc82cb83f2b4afd07ba88e579d71dba
Reviewed-on: https://chromium-review.googlesource.com/c/1337584
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57538}
With Bytecode flushing, the a SharedFunctionInfo's bytecode might be flushed
while the compiler is expecting it to still exist. Rather than continually
getting the bytecode from the SFI, instead bottleneck the points where we get
BytecodeArray from SFIs and maintain an explicit strong reference to the
BytecodeArray from that point onwards to prevent flushing.
BUG=v8:8395
Change-Id: I6a18adec99402838690971eb37ee0617cdc15920
Reviewed-on: https://chromium-review.googlesource.com/c/1309763
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57536}
When one of the inputs to NumberMin or NumberMax is NaN we need to
return NaN, ignoring whatever else was passed. Specifically we cannot
lower `NumberMin(x,y)` to `(x < y) ? x : y` if `x` can be NaN. So
limit this optimization to only perform the above lowering if we
know that `x` is an OrderedNumber and `y` is a PlainNumber (or if
the difference between zeros doesn't matter, an OrderedNumber as
well).
Bug: chromium:905457
Change-Id: If05f19255e14789ab0e277e072469c40e161b85b
Reviewed-on: https://chromium-review.googlesource.com/c/1337576
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57535}
This fixes several problems with instanceof and constant field tracking
in the compiler:
- properly bailout on numbers and non-functions at @@hasInstance.
- deopt on changes of @@hasInstance property.
Bug: v8:8361
Change-Id: I4a1cf9e29d72076f2d37a7c703f18cb2fb8f4040
Reviewed-on: https://chromium-review.googlesource.com/c/1322449
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57532}
This reverts commit bf2f0a0227.
Reason for revert: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20nosnap%20-%20debug/21753
Original change's description:
> [builtins] Support embedded builtins in nosnapshot builds
>
> This CL adds support for embedded builtins in nosnap builds by creating
> and setting an 'embedded blob' after builtin generation. Unlike
> snapshot builds, the blob is not embedded into the .text section but
> located on the C++ heap.
>
> This makes nosnap builds more consistent with mksnapshot, and allows us
> to simplify there and in serializer cctests.
>
> Complications arise from the different workflows we need to support:
>
> 1. the standard mksnapshot build process,
> 2. nosnap builds (which reuse the blob created by the first Isolate),
> 2. and tests with various complicated serialization workflows.
>
> To cover all of these cases, this CL introduces two knobs to twiddle:
>
> 1. A 'sticky' embedded blob which overrides compiled-in default
> embedded blobs at Isolate setup.
> 2. The blob lifecycle can be managed manually or through refcounting.
>
> These are described in more detail in isolate.cc.
>
> Tbr: ulan@chromium.org
> Bug: v8:6666, v8:8350
> Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d
> Reviewed-on: https://chromium-review.googlesource.com/c/1310195
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57523}
TBR=ulan@chromium.org,yangguo@chromium.org,jgruber@chromium.org
Change-Id: I6e35a0cb7186fb50f1012f5c618fb8b48b24a813
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6666, v8:8350
Reviewed-on: https://chromium-review.googlesource.com/c/1337577
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57529}
This reverts commit 0b13f0f517.
Reason for revert: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win32%20-%20debug/17373
Original change's description:
> [snapshot] Emit the embedded blob as assembly instead of inline assembly
>
> The motivation behind this is that MSVC doesn't support inline assembly
> on x64. Emitting the embedded blob as a plain assembly file will give us
> MSVC support (and possibly faster compilation times as a side-effect).
>
> Bug: v8:6666,v8:8349
> Change-Id: I2e6cf072faa9ef406fe721a05b63912c655546c2
> Reviewed-on: https://chromium-review.googlesource.com/c/1329205
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57524}
TBR=yangguo@chromium.org,mvstanton@chromium.org,jgruber@chromium.org
Change-Id: I35f7763f86b4de01e74827a95706b969b43af55e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6666, v8:8349
Reviewed-on: https://chromium-review.googlesource.com/c/1337574
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57528}
The motivation behind this is that MSVC doesn't support inline assembly
on x64. Emitting the embedded blob as a plain assembly file will give us
MSVC support (and possibly faster compilation times as a side-effect).
Bug: v8:6666,v8:8349
Change-Id: I2e6cf072faa9ef406fe721a05b63912c655546c2
Reviewed-on: https://chromium-review.googlesource.com/c/1329205
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57524}
This CL adds support for embedded builtins in nosnap builds by creating
and setting an 'embedded blob' after builtin generation. Unlike
snapshot builds, the blob is not embedded into the .text section but
located on the C++ heap.
This makes nosnap builds more consistent with mksnapshot, and allows us
to simplify there and in serializer cctests.
Complications arise from the different workflows we need to support:
1. the standard mksnapshot build process,
2. nosnap builds (which reuse the blob created by the first Isolate),
2. and tests with various complicated serialization workflows.
To cover all of these cases, this CL introduces two knobs to twiddle:
1. A 'sticky' embedded blob which overrides compiled-in default
embedded blobs at Isolate setup.
2. The blob lifecycle can be managed manually or through refcounting.
These are described in more detail in isolate.cc.
Tbr: ulan@chromium.org
Bug: v8:6666, v8:8350
Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d
Reviewed-on: https://chromium-review.googlesource.com/c/1310195
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57523}
Add regression test to verify array with packed, holey and
dictionary elements.
Change ToUnicodeStringArray to return vector<UnicodeString>
instead allocate raw UnicodeString before calling.
Simplify ToUnicodeStringArray to loop only once.
Bug: chromium:903566
Change-Id: I7ad74179be97d3cf929d2949384dbaa8b66a9a02
Reviewed-on: https://chromium-review.googlesource.com/c/1328642
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57521}
`console.table` used to have a 1k limit on preview properties, which
regressed to 100 during refactoring.
This CL restores the 1k limit, and ensures that `buildEntryPreview`
does not use the 1k limit.
Bug: chromium:903623
Change-Id: I8fab3182a79d1bb6b662e2ff9b229db3d3a889ca
Reviewed-on: https://chromium-review.googlesource.com/c/1332127
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Erik Luo <luoe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57518}
Clang is known to use a lot of stack space for Debug builds, so
this patch lowers the recursion depth of that test after recent
changes made Debug-mode stack frames a bit larger.
a bit of Debug-mode stack space.
Bonus: drops an unnecessary cast from SerializeJSObject to save
Change-Id: I22696a1d80a6a73b5049b018e72cc8a3d8693042
Reviewed-on: https://chromium-review.googlesource.com/c/1334448
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57516}
This allows to call generic callables without mentioning all type
parameters, if they can be deduced from the types passed as arguments.
Bug: v8:7793
Change-Id: Idb37bb6b93c48bd6344c5be19da4e5b19d29593f
Reviewed-on: https://chromium-review.googlesource.com/c/1335936
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57515}
This avoids creating an on-heap copy for import wrappers by directly
adding the {WasmCode} into the native heap instead. It reduces
compilation time as well as useless GC pressure.
R=clemensh@chromium.org
BUG=v8:8423
Change-Id: Ia063523834c963591027c7d1ed78b795d24907bf
Reviewed-on: https://chromium-review.googlesource.com/c/1335566
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57511}
This updates fast path checks in string's search/match/replace/split/matchAll
methods.
Bug: v8:8361
Change-Id: I0377aff21e380d6c718e7471f8964e10c030281b
Reviewed-on: https://chromium-review.googlesource.com/c/1333668
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57509}
Moves the unicode predicate cache tables out of the unicode cache,
and turns them into generic predicates in char-predicates.h which
use static constexpr tables.
This drops the per-isolate cost of unicode caches, and removes the
need for accessing the unicode cache from most files. It does remove
the mutability of the cache, which means that there may be regressions
when parsing non-ASCII identifiers. Most likely the benefits to ASCII
identifiers/keywords will outweigh any non-ASCII costs.
Change-Id: I9a7a8b7c9b22d3e9ede824ab4e27f133ce20a399
Reviewed-on: https://chromium-review.googlesource.com/c/1335564
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57506}
This CL implements AtomicPair operators: Load, Store,
Add, Sub, Or, Xor, And, Exchange and CompareExchange using
runtime on MIPS32R2 and older. MIPS32R6 includes instructions
for 64-bit atomic access so they are implemented using those.
Change-Id: I1309c1ea4771480516ec5a92f7592533bdcb205c
Reviewed-on: https://chromium-review.googlesource.com/c/1326466
Reviewed-by: Sreten Kovacevic <skovacevic@wavecomp.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ivica Bogosavljevic <ibogosavljevic@wavecomp.com>
Cr-Commit-Position: refs/heads/master@{#57496}
- Removes IsRegExp check and special handling when false
- Removes MatchAllIterator
- Extracts previously inlined CreateRegExpStringIterator
- Update comments to match spec text and numbering
Bug: v8:6890
Change-Id: Ie81757a499acc77910f029835fb042e70d86d83d
Reviewed-on: https://chromium-review.googlesource.com/c/1317830
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57488}
This CL is an experiment to get more performance data from the perf-bots
and will likely lead to regressions. The try-bots (see patcheset 9)
indicate some regressions, but it doesn't seem too bad.
Change-Id: Ia173ab20ee2a4904663db0f4ca2ffb196b203c77
Reviewed-on: https://chromium-review.googlesource.com/c/1319763
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57483}
