This ensures that breaking on inlined builtins works, even when
compiling concurrently. This CL also introduces the member
Isolate::AbortConcurrentOptimization.
R=sigurds@chromium.org
Bug: v8:178
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ie6cbb48ebde18036888af2dd715862e7a14ddf9d
Reviewed-on: https://chromium-review.googlesource.com/912468
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51384}
This is a reland of dda0419ecd.
Originally reviewed-on: https://chromium-review.googlesource.com/914513
and landed as refs/heads/master@{#51342}.
Bug: v8:6791
Change-Id: I3b3a069da7a0e64c38a81b3110dc5ece4887cb19
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/924665
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51352}
- Replaces calls to Allocator Reserve, Free, and SetPermissions
with equivalent page allocator calls (allocation.h).
- Un-implements these methods to catch usage, in preparation for
removing these.
Bug: chromium:799573
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Id233b7a9cfc8e332c64e514f6359e8b670c2d75e
Reviewed-on: https://chromium-review.googlesource.com/911883
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51340}
This doesn't enable the warning yet, but adds V8_FALLTHROUGH annotations
in enough places so that v8 can build with the warning on on my linux box.
Found one real bug
(in effect-control-linearizer.cc,
https://chromium-review.googlesource.com/c/v8/v8/+/850392/3/src/compiler/effect-control-linearizer.cc#825
).
Bug: chromium:812686
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I3542550b9c24b545641d0f0fc43f28f2780b0ab3
Reviewed-on: https://chromium-review.googlesource.com/911731
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51322}
Tbr: jarin@chromium.org
Change-Id: I17477e2c82398b228a366a3d1fd8eb521dd51eae
Reviewed-on: https://chromium-review.googlesource.com/922270
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51317}
instance_class_name takes up space unnecessarily, and %_ClassOf and
class_name implement [[Class]] which isn't part of ES2015+ anymore.
Bug:
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I3a73f732ad83a616817fde9992f4e4d584638fa8
Reviewed-on: https://chromium-review.googlesource.com/776683
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51309}
Implements the change outlined in https://github.com/tc39/ecma262/pull/890,
which has been ratified and pulled into the specification. In particular,
template callsite objects are no longer kept in a global, eternal Map, but
are instead associated with their callsite, which can be collected. This
prevents a memory leak incurred by TaggedTemplate calls.
Changes, summarized:
- Remove the TemplateMap and TemplateMapShape objects, instead caching
template objects in the feedback vector.
- Remove the `hash` member of TemplateObjectDescriptor, and the Equals
method (used by TemplateMap)
- Add a new FeedbackSlotKind (kTemplateObject), which behaves similarly
to FeedbackSlotKind::kLiteral, but prevents eval caching. This ensures
that a new feedback vector is always created for eval() containing tagged
templates, even when the CompilationCache is used.
- GetTemplateObject bytecode now takes a feedback index, and only calls
into the runtime if the feedback is Smi::kZero (uninitialized).
BUG=v8:3230, v8:2891
R=littledan@chromium.org, yangguo@chromium.org, bmeurer@chromium.org,
rmcilroy@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I7827bc148d3d93e2b056ebf63dd624da196ad423
Reviewed-on: https://chromium-review.googlesource.com/624564
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51248}
some time the output of these two could be the same
if machine is fast enough.
Change-Id: I1d9c0191657abae3d053517d45059065df2d44dc
Reviewed-on: https://chromium-review.googlesource.com/911873
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#51247}
Moves generation of speculation poison to be based on the PC target vs the
actual PC being executed. The speculation poison is generated in the prologue
of the generated code if CompilationInfo::kGenerateSpeculationPoison is set.
The result is stored in a known register, which can then be read using the
SpeculationPoison machine node.
Currently we need to ensure the SpeculationPoison node is scheduled right after
the code prologue so that the poison register doesn't get clobbered. This is
currently not verified, however it's only use is in RawMachineAssembler where
it is manually scheduled early.
The Ignition bytecode handlers are updated to use this speculation poison
rather than one generated by comparing the target bytecode.
BUG=chromium:798964
Change-Id: I2a3d0cfc694e88d7a8fe893282bd5082f693d5e2
Reviewed-on: https://chromium-review.googlesource.com/893160
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51229}
This is a purely cosmetic change. Rename all local variables and
parameters of type CallDescriptor* to "call_descriptor".
For locals that are now named "call_descriptor", use auto upon
initialization, following the Google style guide
(https://google.github.io/styleguide/cppguide.html#auto).
Note: fields in structs and classes were not renamed in this CL.
R=clemensh@chromium.org,mstarzinger@chromium.org,jarin@chromium.org
Change-Id: Ic6f7afdba12f7b97741b098a9d0e0f58c41c587e
Reviewed-on: https://chromium-review.googlesource.com/909866
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51223}
It will record the time-to-schedule-after-job-start for different
task types to try to highlight use cases where contention might
be a problem (and show improvements to it later).
Also introducing AsyncTimedHistogram to support this use case whose
reported timings go beyond a single scope (i.e. the async version of
ScopedTimedHistogram).
Bug: chromium:807606
Change-Id: Ib4d581fa8b001723dfe8c91102280e9608b4fabb
Reviewed-on: https://chromium-review.googlesource.com/899365
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51131}
Copied as-is modulo compile tweaks from Chromium's base.
Copied tests highlighting existing overflow issues with V8's impl...
TimeDelta::Max() will initially be used in V8 to flag events that
never triggered in a TimedHistogram.
Also constexpr'ed a few things while I was in there, it's harmless
at worst and helps a little at best.
Ideally would constexpr all the Time*::From*() methods like in
Chromium but that has inlining implications and I don't know the
impact that could have on V8.
Bug: chromium:807606
Change-Id: If5aa92759d985be070e12af4dd20f0159169048b
Reviewed-on: https://chromium-review.googlesource.com/899342
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51073}
- Adds a DCHECK to AllocatePages to enforce hint address alignment.
- Adds a DCHECK to AllocatePages to make length a multiple of allocation
granularity.
- Properly aligns the hint address in MemoryAllocator::AllocateChunk
to MemoryChunk::kAlignment.
This is to conform more closely to Chromium's page allocator API.
Bug:chromium:756050
Change-Id: Ib991fa80609834107829a9559f4b5b6b0996fc72
Reviewed-on: https://chromium-review.googlesource.com/898095
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51065}
Where the value we are switching on is a constant, we can just look
through each IfValue case and replace the switch and go straight to
the appropriate case. If no case matches, expect and go to the
IfDefault.
For the (unrealistic) example in the linked bug, this improves
performance ~1.5x.
Bug: v8:7389
Change-Id: I7ffe209bda9ed22571ea106396b18e0bcf9a1e22
Reviewed-on: https://chromium-review.googlesource.com/893141
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51029}
It was already always high-resolution on POSIX but was never high
resolution on Windows. Windows does support low latency high-resolution
timers for the majority of our user base.
TimeTicks::HighResolutionNow() was only explicitly requested in testing
frameworks. As such I left the call in place but made it DCHECK that
it's running on a Windows machine on which high-resolution clocks are
used. This confirms that none of our test fleet has regressed with this
change (the previous HighResolutionNow() used to be slightly more
aggressive and also do it in a few configurations where we now fallback
to low-resolution now).
This implementation was copied as-is (modulo minor v8 API
compatibility tweaks). These implementations were the same in the
past but had diverged when, sadly, the same bug was fixed separately
years apart, in Chromium and V8:
chromium: https://codereview.chromium.org/1284053004 + https://codereview.chromium.org/2393953003
v8: https://codereview.chromium.org/1304873011
This is a prerequisite to add metrics around parallel task execution
(low-resolution clocks are useless at that level, but we also don't want
to incur high-latency clocks on machines that can't afford it cheaply).
Bug: chromium:807606
Change-Id: Id18e7be895d8431ebd0e565a1bdf358fe7838489
Reviewed-on: https://chromium-review.googlesource.com/897485
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51027}
Otherwise bots with a low number of cores will hang trying to schedule
a mere 4 tasks.
This change allowing scheduling of an arbitrary number of test tasks,
the count was also augmented to better stress test the system.
Bug: chromium:805932
Change-Id: Ia10cd583c0675c256b4fd5d2765b50855d77a7f9
Reviewed-on: https://chromium-review.googlesource.com/895584
Commit-Queue: Gabriel Charette <gab@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51019}
This is a reland of 957ac3641c.
To avoid a race condition TSAN found when accessing FLAG_turbo_disable_switch_jump_table
in the InstructionSelector, this now threads the flag through the CompilationInfo.
Original change's description:
> [turbofan] disable indirect jumps in Turbofan generated switches
>
> Bug:
> Change-Id: I326bf518f895e7c030376210e7797f3dd4a9ae1f
> Reviewed-on: https://chromium-review.googlesource.com/873643
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50984}
Change-Id: I76c2804f140cc116e30881bfd05365a09240e605
Reviewed-on: https://chromium-review.googlesource.com/895643
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51014}
This is a reland of 0db74d4974.
Original change's description:
> [test] Random seed processor
>
> 1. --total-timeout-sec now available for ./run-tests.py. It can be
> useful with infinite seed stressing
> 2. random seed dropped from the context. Now JSON progress indicator
> gets it from the list of command args.
>
> Bug: v8:6917
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: I73e535bc8face9b913c696b8d5e3a246fa231004
> Reviewed-on: https://chromium-review.googlesource.com/888524
> Commit-Queue: Michał Majewski <majeski@google.com>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50964}
Bug: v8:6917
Change-Id: I1ea376a4abffce5ab65f4834ea7e6d6011765ffa
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/894204
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michał Majewski <majeski@google.com>
Cr-Commit-Position: refs/heads/master@{#50978}
This reverts commit 0db74d4974.
Reason for revert: https://chromium-swarm.appspot.com/task?id=3b609f9976bac610&refresh=10&show_raw=1
Original change's description:
> [test] Random seed processor
>
> 1. --total-timeout-sec now available for ./run-tests.py. It can be
> useful with infinite seed stressing
> 2. random seed dropped from the context. Now JSON progress indicator
> gets it from the list of command args.
>
> Bug: v8:6917
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: I73e535bc8face9b913c696b8d5e3a246fa231004
> Reviewed-on: https://chromium-review.googlesource.com/888524
> Commit-Queue: Michał Majewski <majeski@google.com>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50964}
TBR=machenbach@chromium.org,sergiyb@chromium.org,majeski@google.com
Change-Id: I2d96ea328cda2d09b01ff455e47c77d567fafe00
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6917
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/894522
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50970}
This is a reland of 76195d9e08.
It was reverted because the new parallel tasks (with higher number
of workers) hang on client.v8.ports bots. Since each test task steals
the worker thread it's assigned but only processes one item before
waiting for completion by others: I think the problem is that there
aren't enough workers in client.v8.ports' config. There aren't any
try bots for this config... reduce the tests to use 4 tasks and
hope for the best (i.e. a 4 core machine that uses "num cores")...
Original change's description:
> Smoother distribution of worker assignment in parallel task array.
>
> This is a merge of https://chromium-review.googlesource.com/c/v8/v8/+/888704
> and https://chromium-review.googlesource.com/c/v8/v8/+/887084
>
> Which implements the fix in CL 887084 correctly in a world where
> there can be more tasks_ than items_ (crbug.com/806237).
>
> Bug: chromium:805932
> Change-Id: I05401be4fdce442644a8973281a9d88bd959b271
> Reviewed-on: https://chromium-review.googlesource.com/892883
> Commit-Queue: Gabriel Charette <gab@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50956}
Reverted-on: https://chromium-review.googlesource.com/893462
Bug: chromium:805932
Change-Id: I4d0bda3b9f52e9160e613a8f34a95e48b814bb9e
Reviewed-on: https://chromium-review.googlesource.com/893362
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50967}
This reverts commit 76195d9e08.
Reason for revert: New parallel tests timeout on the waterfall (I think because it's configured to use less worker threads and TaskProcessingOneItem is currently designed to steal a worker but only process one item...).
Original change's description:
> Smoother distribution of worker assignment in parallel task array.
>
> This is a merge of https://chromium-review.googlesource.com/c/v8/v8/+/888704
> and https://chromium-review.googlesource.com/c/v8/v8/+/887084
>
> Which implements the fix in CL 887084 correctly in a world where
> there can be more tasks_ than items_ (crbug.com/806237).
>
> Bug: chromium:805932
> Change-Id: I05401be4fdce442644a8973281a9d88bd959b271
> Reviewed-on: https://chromium-review.googlesource.com/892883
> Commit-Queue: Gabriel Charette <gab@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50956}
TBR=gab@chromium.org,hpayer@chromium.org,mlippautz@chromium.org
Change-Id: Icf52eb3afeb9467557c1e0db6922d590466943f0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:805932
Reviewed-on: https://chromium-review.googlesource.com/893462
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50965}
1. --total-timeout-sec now available for ./run-tests.py. It can be
useful with infinite seed stressing
2. random seed dropped from the context. Now JSON progress indicator
gets it from the list of command args.
Bug: v8:6917
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I73e535bc8face9b913c696b8d5e3a246fa231004
Reviewed-on: https://chromium-review.googlesource.com/888524
Commit-Queue: Michał Majewski <majeski@google.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50964}
This reverts commit 8a27c7d396.
Reason for revert:
Having more tasks then work items is intentional in some use cases, i.e. Scavenging where RunInParallel() does parallel processing on a dynamic workload *after* the initial set of work items:
{
barrier_->Start();
TimedScope scope(&scavenging_time);
PageScavengingItem* item = nullptr;
while ((item = GetItem<PageScavengingItem>()) != nullptr) {
item->Process(scavenger_);
item->MarkFinished();
}
do {
scavenger_->Process(barrier_);
} while (!barrier_->Wait());
scavenger_->Process();
}
Original change's description:
> v8::ItemParallelJob : Do not launch more Tasks than there are Items to process.
>
> Except when there are 0 items. For some reason I don't quite understand yet, not
> calling Run() on tasks_[0] when there are 0 items results in DCHECKs...
>
> Bug: chromium:806237
> Change-Id: I38c8fffde64a42f93f4efda492832651137eebd7
> Reviewed-on: https://chromium-review.googlesource.com/888704
> Commit-Queue: Gabriel Charette <gab@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50924}
TBR=gab@chromium.org,mlippautz@chromium.org
Change-Id: Iad2ab16bb41f339de8e3fbca1c08c5d26b8a0111
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:806237
Reviewed-on: https://chromium-review.googlesource.com/891186
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50928}
Except when there are 0 items. For some reason I don't quite understand yet, not
calling Run() on tasks_[0] when there are 0 items results in DCHECKs...
Bug: chromium:806237
Change-Id: I38c8fffde64a42f93f4efda492832651137eebd7
Reviewed-on: https://chromium-review.googlesource.com/888704
Commit-Queue: Gabriel Charette <gab@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50924}
This reverts commit bf19e60cc5.
Reason for revert: Two issues discovered with W^X in V8's 6.5 branch (see v8:7272 and chromium:793428). Still need a way to disable the feature.
Original change's description:
> [platform] Remove {PageAllocator::kReadWriteExecute}.
>
> Now that write-protection of code memory is enabled everywhere and V8 is
> fully W^X compliant, we can remove the permission mode in question.
>
> R=hpayer@chromium.org
> BUG=v8:6792
>
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I80fe95ac6bb0e2d1ad6d993154ce45d492d941be
> Reviewed-on: https://chromium-review.googlesource.com/866855
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50770}
TBR=bbudge@chromium.org,mstarzinger@chromium.org,hpayer@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:6792
Change-Id: If4a205497ac83084a4092560363affb13b391462
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/883461
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50834}
Do a step before selecting the limit for the next step. However, as seen
on crbug.com/795323, while this fix makes us more precise in our
accounting, we do ending up seeing steps more frequently. This ends up
invoking the idle scavenger more frequently. To compensate, we adjust
the idle scavenger step size.
Bug:
Change-Id: I7bc2b1785a564dee27aa3ce6a5a196efe9eb6283
Reviewed-on: https://chromium-review.googlesource.com/838440
Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50816}
Currently, yields and awaits inside loops compile to bytecode which
switches to the top of the loop header, and switch again once inside the
loop. This is to make loops reducible.
This replaces this switching logic with a single switch bytecode that
directly jumps to the bytecode being resumed. Among other things, this
allows us to no longer maintain the generator state after the switch at
the top of the function, and avoid having to track loop suspend counts.
TurboFan still needs to have reducible loops, so we now insert loop
header switches during bytecode graph building, for suspends that are
discovered to be inside loops during bytecode analysis. We do, however,
do some environment magic across loop headers since we know that we will
continue switching if and only if we reached that loop header via a
generator resume. This allows us to generate fewer phis and tighten
liveness.
Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385
Reviewed-on: https://chromium-review.googlesource.com/866734
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50804}
Now that write-protection of code memory is enabled everywhere and V8 is
fully W^X compliant, we can remove the permission mode in question.
R=hpayer@chromium.org
BUG=v8:6792
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I80fe95ac6bb0e2d1ad6d993154ce45d492d941be
Reviewed-on: https://chromium-review.googlesource.com/866855
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50770}
Instead of requiring the pattern that a SuspendGenerator must be
followed by a Return, make SuspendGenerator return directly. This can,
in the future, simplify some of the reasoning around generator suspends.
Change-Id: I94c0156a89dc0e1c0bc306bc57acf766f3b4deb5
Reviewed-on: https://chromium-review.googlesource.com/857463
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50748}
This is the v8 side of changes; blink changes are at https://chromium-review.googlesource.com/c/chromium/src/+/809228
BUG=chromium:716320
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ia77764aed09dd609bf2304fe3c392a0e8ee16334
Reviewed-on: https://chromium-review.googlesource.com/847337
Reviewed-by: v8 autoroll <v8-autoroll@chromium.org>
Cr-Original-Commit-Position: refs/heads/6.5.123@{#1}
Cr-Original-Branched-From: 2a8e1e4a9470bc3a92c58fde069901497a3f3fed-refs/heads/master@{#50331}
Reviewed-on: https://chromium-review.googlesource.com/854395
Commit-Queue: Malcolm White <malcolmwhite@google.com>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50699}
This works around a bug in the libc++ implementation of bitset
(https://bugs.llvm.org/show_bug.cgi?id=35438) resulting in high
bits outside the bitset leaking through, breaking the ordering
invariant of PersistentMap::iterator. This did not surface so far
because the hash values used in escape analysis so far all only used
32 bits.
Bug:
Change-Id: I18ce703020bf1fb3e1b412edaa899fa1afe0bba0
Reviewed-on: https://chromium-review.googlesource.com/793613
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50684}
With the current attempt, trying to iterate a const ZoneChunkList doesn't even
compile. See the bug for more info.
R=marja@chromium.org
Bug: v8:6473
Change-Id: I8de7e887398be7ba5da14dc540dd40b30df2c3fe
Reviewed-on: https://chromium-review.googlesource.com/868332
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50675}
