This CL changes how we handle the case when both --regexp-tier-up and
--regexp-interpret-all flags are on. Previously, we had a CHECK that would
crash if both flags were turned on, now we turn off the tier-up flag and
print a warning message.
Change-Id: I902a59cac9aaf316be05ab2acaee233aa32e023d
Bug: chromium:1002242
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1795353
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Ana Pesko <anapesko@google.com>
Cr-Commit-Position: refs/heads/master@{#63648}
After https://crrev.com/c/1793065 the test should be fast enough to
execute it everywhere.
R=mslekova@chromium.org
Bug: v8:9696, v8:7783
Change-Id: I2485d703d6e973217eddde2f2814e31f7fcd8a61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1795343
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63647}
An upcoming CL will remove the COLLECT_NON_LOCALS support of the
ScopeIterator. The DebugStackTraceIterator uses the list of non-locals
to restore the receiver for arrow functions.
This CL extracts the relevant logic into a small helper and calls
it directly.
Change-Id: Ia396fd599e41ca65810497d2f5228619cfdf7cc4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1795347
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63645}
This CL is necessary for disabling write-barriers that involoves
referencing pages via address arithmetic, which is required from
third-party heap implementation.
Change-Id: I1d3f572d48015e5c8cf691b2dc71a32834621c2f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781008
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63644}
Since we switched to C++14 now, we can use {std::make_unique} instead
of our own {base::make_unique} from {template-utils.h}.
R=mstarzinger@chromium.org, yangguo@chromium.org
Bug: v8:9687
No-Try: true
Change-Id: I660eb30038bbb079cee93c7861cd87ccd134f01b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789300
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63642}
We don't handle all cases for stores to typed arrays in the builtins
related to storing a property. Bailout to runtime when storing into
a typed array if the property is not found on the object.
Bug: chromium:996161
Change-Id: I684c7c4f526b15cdfb5bfe3fd23218910486a59e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789396
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63639}
No invalidation of slots necessary for String::MakeThin. ThinString
only stores tagged value, so it can't store an untagged value in a
recorded slot. CreateFillerObjectAt takes care of slots in case of
right-trimming objects.
Bug: v8:9454
Change-Id: Id16e8ebceb334a845bdbf77282fbeb2069efce7d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1794682
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63637}
When analyzing functions scopes with the script_scope as parent, don't
skip migrating unresolved variables upwards if we could still be inside
an arrow head, which means accesses to those variables will be
correctly context allocated.
Bug: v8:8510, chromium:1000094
Change-Id: I684f2f8bc692de420203990f93e5c943b5b769c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789705
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63635}
Fix build errors introduced by
commit af063685fe
Change-Id: I467ea39f020d07bed00875f69152191b94029dd1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1794327
Auto-Submit: Mu Tao <pamilty@gmail.com>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63633}
Port 9f01d5c1e0
Original Commit Message:
Stack overflow checks are typically implemented as part of the TurboFan
graph of a function. This means that the stack check code is executed
after frame construction. When a frame is too big, though, there may not
be enough space on the stack anymore to throw the stack overflow
exception after frame construction. With this CL we do an additional
stack check before frame construction for functions with big frames.
As discussed offline with mstarzinger, I do this change currently only
for WebAssembly.
This CL contains only the changes for arm. I will do the other platforms
in separate CLs
R=xwafish@gmail.com
Change-Id: I46c6dd8fac1385e5da13e03cfffd9c640a7c2c57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792582
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Auto-Submit: Mu Tao <pamilty@gmail.com>
Cr-Commit-Position: refs/heads/master@{#63632}
It looks like the loop is there to create objects and trigger GC. It's
also tailored to Crankshaft, which was removed long ago.
This code currently times out on some arm bots, and it's hard to see
any value in it. Thus remove it.
R=mslekova@chromium.org
Change-Id: Ia47d4f70d679f79cfea523f467ff7adc3360cf6c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1793065
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63630}
v8_debug_helper attempts to flag known object pointers when it can
recognize them, even if the memory pointed to is not available in the
crash dump. In ptr-compr builds, the first pages of the map space,
read-only space, and old space are always at the same offsets within the
heap reservation region, so we can more easily detect known objects.
Bug: v8:9376
Change-Id: I04e0d2357143d753f575f556e94f8fd42ce9d811
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783729
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63624}
This CL implements the tier-up strategy where the interpreter can be used for
an arbitrary number of executions for every regex, before tiering-up to the
compiler. The only exception is for functional global replaces, where we
eagerly tier-up to native code right away.
To use the tier-up logic --regexp-tier-up=value needs to be set. It is
currently set to 0 by default.
Change-Id: I770857e5eae710a952fe47661cb42957c53848b4
Bug: v8:9566
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789299
Commit-Queue: Ana Pesko <anapesko@google.com>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63623}
The fuzzer found a crash when we want to execute the {valueOf} function
of an imported value for an i64-global. The problem is that we cannot
execute JavaScript at that moment (I did not check why, I guess we open
some scope at some point). I checked the WebAssembly spec now, and it
defines that only numbers are valid values for imported globals. I
adjust our bigint implementation accordingly with this CL, i.e. that
only bigint values are valid as imported i64-globalsl.
I also created github issues to discuss this problem.
R=jkummerow@chromium.org
Bug: chromium:1001804
Change-Id: I47f0b31fab53163346f341ad290fd3c58e7707bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792167
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63621}
... to make them unique. With this fix the --trace-turbo no longer
overwrites bytecode handler graphs and --trace-turbo-filter allows
to select exact bytecode handler version.
Bug: v8:9396
Change-Id: I260edc8872e320aadd5d70aa95cf5bf2cd24b22f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792904
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63620}
TNodified:
* AbortIfRegisterCountInvalid
* MaybeDropFrames
* TraceBytecodeDispatch
* UpdateInterruptBudget
* OperandOffset
There are currently no more Node* in interpreter-assembler!
Bug: v8:6949
Change-Id: I352a1fd18444c6ffb0f85d95f5da2e3e4a1681e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787432
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63618}
This reverts commit 9da3483136
Original change's description:
> "Reland x4 [arraybuffer] Rearchitect backing store ownership"
>
> This is a reland of bc33f5aeba
>
> Contributed by titzer@chromium.org
>
> Original change's description:
> > [arraybuffer] Rearchitect backing store ownership
> >
> > This CL completely rearchitects the ownership of array buffer backing stores,
> > consolidating ownership into a {BackingStore} C++ object that is tracked
> > throughout V8 using unique_ptr and shared_ptr where appropriate.
> >
> > Overall, lifetime management is simpler and more explicit. The numerous
> > ways that array buffers were initialized have been streamlined to one
> > Attach() method on JSArrayBuffer. The array buffer tracker in the
> > GC implementation now manages std::shared_ptr<BackingStore> pointers,
> > and the construction and destruction of the BackingStore object itself
> > handles the underlying page or embedder-allocated memory.
> >
> > The embedder API remains unchanged for now. We use the
> > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> > keep the backing store alive properly, even in the case of aliases
> > from live heap objects. Thus the embedder has a lower chance of making
> > a mistake. Long-term, we should move the embedder to a model where they
> > manage backing stores using shared_ptr to an opaque backing store object.
>
> TBR=yangguo@chromium.org
>
> BUG=v8:9380,v8:9221,chromium:986318
>
> Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63041}
TBR=yangguo@chromium.org
Change-Id: I3cc4bb80081c662b1751234bc16a821c20e744be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792166
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63617}
This increases readability of the wasm-stepping test significantly.
Drive-by: Use more 'let' instead of 'var'.
R=yangguo@chromium.org
Change-Id: If80ba3a4b92cd3ab1c994e17fb8f40f5526517da
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789298
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63616}
After https://crrev.com/c/1789294, the {AddAndPublishAnonymousCode} has
only a single caller, {AddCodeForTesting}. Thus inline the method there.
R=mstarzinger@chromium.org
Change-Id: I698b37baa55221b82ead0b0bb8205233693ffced
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789703
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63614}
Getting the type from the internal object avoids a costly allocation.
Not doing it this way all along was an oversight.
Change-Id: I22197cbb6ab2a68dd0faba78152e7cc2eb473e23
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1790102
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63613}
The bot that runs gcmole was failing before
https://crrev.com/c/1789707 because the test file was missing.
It returned with exit status 0 anyway though. After fixing the
original fault, this CL ensures that the gcmole tests also
trigger an error on the bot(s) if they fail.
R=mstarzinger@chromium.org
CC=mslekova@chromium.org
Change-Id: I29ae40301062baadfcd38b26c336c5749924b0d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789702
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63612}
This is a reland of b1c3ca2a71
Original change's description:
> [heap] Reschedule concurrent marking tasks earlier
>
> Currently we reschedule concurrent marking tasks if all tasks finish.
> This is too conservative and we can improve performance by rescheduling
> finished tasks without waiting for all other tasks.
>
> As a drive-by this also changes task_count_ to total_task_count_.
>
> Change-Id: If0b3bd45ce6d52f6bcd0065dd8d3efe9ea84184a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789142
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63593}
Change-Id: Id18bbb3cab85cd38bb7d2f21611825252ed4a1dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789288
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63610}
No-embed builds are deprecated since v7.4 and will successively be
removed soon.
These no-embed builds complicate the design of far jump tables, so
we stop to support this configuration now.
R=mstarzinger@chromium.org
CC=szuend@chromium.org, jgruber@chromium.org, hablich@chromium.org
Bug: v8:8519, v8:9477
Change-Id: I6ab6f83019e7a182a50f4c599f3dd8c03aa2c02f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789294
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Hablich <hablich@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63609}
The bots currently fail to run the gcmole self tests, because the file
is not contained in the generated archive.
This CL fixes that.
R=mstarzinger@chromium.orgCC=mslekova@chromium.org
Change-Id: I691c207be1809516a5cc5e250287427674146a7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789707
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63608}
Slots are always valid inside an invalidated area when outside the
respective object's current size. This allows us to remove the size
from the InvalidatedSlots data structure.
This change was enabled by https://crrev.com/c/1771793. Reland after
revert in https://crrev.com/c/1783106, this CL was not the culprit
of the issue (chromium:1000404).
Bug: v8:9454
Change-Id: I823d34670515924bf74200daa21a834044087310
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787431
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63607}
Filtering was reverted in https://crrev.com/c/1773252 because of
chromium:998256, but this issue seems to be unrelated.
Bug: v8:9454
Change-Id: Ie266976c8fc664fe2a7395198a010307f5297f25
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792163
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63606}
It is not recommended to define type alias in C++ header file. cctest defines
type alias `using Label=CodeAssemblerLabel` in anonymous namespace under
namespace `v8::internal::compiler` in test-code-assembler.cc. This is fine
because this type alias is expected to take effect only in this .cc file. But in
jumbo build, multiple source files are combined as a single one, and the
previous `Label` type alias could shadow definition of `Label` from other header
file (for example, v8/src/codegen/label.h which is included by another .cc file)
This is totally unexpected and triggers bad class layout and accessing in the
latter .cc file for the places where `Label` is referenced.
This change fixes cctest from Windows ARM64 jumbo build, but it applies to
other architectures too.
Bug: chromium:893460
Change-Id: Ib2e9df76f6e3371b3940649668c5d13e6b36f028
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1788537
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Tom Tan <Tom.Tan@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#63605}
ScopeIterator was changed to re-parse the whole script instead of
just a single function. The CL in question went through a few
iterations. At one point, it was necessary to wrangle the source
position of generator functions to correctly identify their
closure scope. This is no longer necessary and this CL removes
the manual source position adjustment.
Change-Id: If1a61ed32a903997b70a62cd464198f3dffa385a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792162
Auto-Submit: Simon Zünd <szuend@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63604}
Currently this is very similar to TurboFan's OptimizeGraph phase, but avoids
a number of passes to reduce optimization time. With time this will have more
differences.
BUG=v8:9684
Change-Id: Id416385e55fa52e1103fd103032c6db86c17f047
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784295
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63602}
GetMaxBackgroundTasks should return 0 in predictable mode, since
compilation is done in the foreground.
R=clemensh@chromium.org
Change-Id: I4a617cadb53ca91ee21e40c46a93d54e2a1ceb8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789301
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63600}