Reland of https://chromium-review.googlesource.com/c/v8/v8/+/727893
The crashes should be fixed by https://chromium-review.googlesource.com/c/v8/v8/+/763531
Original change's description:
> Revert "Reland^5 "[turbofan] eagerly prune None types and deadness from the graph""
>
> This reverts commit ac0661b358.
>
> Reason for revert: Clusterfuzz unhappy: chromium:783019 chromium:783035
>
> Original change's description:
> > Reland^5 "[turbofan] eagerly prune None types and deadness from the graph"
> >
> > This gives up on earlier attempts to interpret DeadValue as a signal of
> > unreachable code. This does not work because free-floating dead value
> > nodes, and even pure branch nodes that use them, can get scheduled so
> > early that they get reachable. Instead, we now eagerly remove branches
> > that use DeadValue in DeadCodeElimination and replace DeadValue inputs
> > to value phi nodes with dummy values.
> >
> > Reland of https://chromium-review.googlesource.com/715716
> >
> > Bug: chromium:741225 chromium:776256
> > Change-Id: I251efd507c967d4a8882ad8fd2fd96c4185781fe
> > Reviewed-on: https://chromium-review.googlesource.com/727893
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#49188}
>
> TBR=jarin@chromium.org,tebbi@chromium.org
>
> Bug: chromium:741225 chromium:776256 chromium:783019 chromium:783035
> Change-Id: I6a8fa3a08ce2824a858ae01817688e63ed1f442e
> Reviewed-on: https://chromium-review.googlesource.com/758770
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49262}
TBR=jarin@chromium.org,tebbi@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:741225 chromium:776256 chromium:783019 chromium:783035
Change-Id: I6c02b4beb02997ec34015ed2f6791a93c70f5e36
Reviewed-on: https://chromium-review.googlesource.com/772150
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49429}
Now that UnoptimizedCompileJob only has three stages, move the logic for
stepping between these stages out of UnoptimizedCompileJob and back into
CompilerDispatcher.
BUG=v8:5203
Change-Id: I3bb776e14ef9da801dc9792e9e643b8026135060
Reviewed-on: https://chromium-review.googlesource.com/774743
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49422}
Simplifies the unoptimized compile job to have only three steps, the
on-main-thread prepare step, the off-thread compile step and the
on-main-thread finalization step.
As part of this change, the compiler dispatcher no longer supports
functions with outer scopeinfo's, since these need to be analysed on the
main thread.
BUG=v8:5203
Change-Id: Ifb378ef81bd47b6f6d4037a3b8acf88660896c4e
Reviewed-on: https://chromium-review.googlesource.com/774558
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49413}
Removes Isolate from compilation info and instead threads isolate through
function calls. This ensures that we can't access the isolate from
background thread compilations.
BUG=v8:5203
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I9a4e1cd67c4736e36f609360b996fb55166a1c50
Reviewed-on: https://chromium-review.googlesource.com/751745
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49386}
The streaming decoder allocates the whole section buffer of the code
section when it reads the section length of the code section. Therefore
we have to check that the different parts of the code section actually
use all the bytes, and that the different parts of the code section do
not need more bytes than available. The check that all bytes are used
was missing in the case where the code section contained zero functions.
In addition, this CL adds some tracing to the streaming decoder which
may be useful in future debugging.
R=clemensh@chromium.org
Bug: chromium:783595
Change-Id: Icf056c25a3000b4a08a791939dab0ccde9fc3f80
Reviewed-on: https://chromium-review.googlesource.com/768788
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49380}
There was a data race in the access of the foreground_task_runner_map_.
I protect each access to foreground_task_runner_map_ with a lock now.
Original change's description:
> [platform] Implement TaskRunners in the DefaultPlatform
>
> This CL implements the TaskRunners in the DefaultPlatform which has been
> added recently to the platform API. In addition I changed how task
> posting works on the DefaultPlatform.
>
> With this implementation the DefaultPlatform keeps one
> DefaultForegroundTaskRunner per isolate, plus one
> DefaultBackgroundTaskRunner. The DefaultPlatform owns these TaskRunners
> with a shared_ptr, which is also shared with any caller of
> GetForegroundTaskRunner or GetBackgroundTaskrunner.
>
> This CL moves the task management from the DefaultPlatform to the
> TaskRunners. The DefaultForegroundTaskRunner owns and manages the the
> task queue, the delayed task queue, and the idle task queue. The
> DefaultBackgroundTaskRunner owns the WorkerThread pool and the
> background task queue.
>
> In addition changed many Task* to std::unique_ptr<Task> to document task
> ownership.
>
> R=rmcilroy@chromium.org
>
> Change-Id: Ib9a01f1f45e5b48844a37d801f884210ec3f6c27
> Reviewed-on: https://chromium-review.googlesource.com/753583
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49354}
Change-Id: Iddccdb07bde1a799815ec6ed6af37082df4987c7
Reviewed-on: https://chromium-review.googlesource.com/770970
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49379}
This is a reland of 4899bcb66d
This is a reland of b73ee3344a
Original change's description:
> [Memory] Use OS::Allocate for all OS memory allocations.
>
> - Eliminates OS::ReserveRegion and OS::ReserveAlignedRegion.
> - Changes OS::Allocate to take alignment parameter, reorders parameters
> to match page_allocator.
> - Since the size of memory allocation can be deduced, don't return the
> amount of memory allocated.
> - Changes reservation of aligned address space. Before we would reserve
> (size + alignment) rounded up to page size. This is too much, because
> maximum misalignment is (alignment - page_size).
> - On Windows and Cygwin, we release an oversize allocation and
> immediately retry at the aligned address in the allocation. If we
> lose the address due to a race, we just retry.
> - Clean up all the calls to OS::Allocate in codegen and tests by adding
> helper AllocateSystemPage function (allocation.h) and
> AllocateAssemblerBuffer (cctest.h).
> - Changes 'assm' to 'masm' in some targets for consistency when using
> a macro-assembler.
>
> - Eliminates OS::ReleaseRegion, replacing with calls to OS::Free.
> - Adds bool return value to OS::Free.
> - Cleans up types of flags, protection on Windows and Cygwin.
> Bug: chromium:756050
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I306dbe042cc867670fdc935abca29db074b0da71
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Iad3c025334e8f8d7d647be99a36a11ee449c9087
Reviewed-on: https://chromium-review.googlesource.com/767014
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49363}
This reverts commit 8de2e6db02.
Reason for revert: Suspect for:
https://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20nosnap%20-%20shared/builds/24237https://build.chromium.org/p/client.v8/builders/V8%20Win64/builds/20896
Original change's description:
> [platform] Implement TaskRunners in the DefaultPlatform
>
> This CL implements the TaskRunners in the DefaultPlatform which has been
> added recently to the platform API. In addition I changed how task
> posting works on the DefaultPlatform.
>
> With this implementation the DefaultPlatform keeps one
> DefaultForegroundTaskRunner per isolate, plus one
> DefaultBackgroundTaskRunner. The DefaultPlatform owns these TaskRunners
> with a shared_ptr, which is also shared with any caller of
> GetForegroundTaskRunner or GetBackgroundTaskrunner.
>
> This CL moves the task management from the DefaultPlatform to the
> TaskRunners. The DefaultForegroundTaskRunner owns and manages the the
> task queue, the delayed task queue, and the idle task queue. The
> DefaultBackgroundTaskRunner owns the WorkerThread pool and the
> background task queue.
>
> In addition changed many Task* to std::unique_ptr<Task> to document task
> ownership.
>
> R=rmcilroy@chromium.org
>
> Change-Id: Ib9a01f1f45e5b48844a37d801f884210ec3f6c27
> Reviewed-on: https://chromium-review.googlesource.com/753583
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49354}
TBR=rmcilroy@chromium.org,ahaas@chromium.org
Change-Id: I6c381915a2cae8ea1a0d21d6cfa6e797ccd2d947
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/768748
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49357}
This CL implements the TaskRunners in the DefaultPlatform which has been
added recently to the platform API. In addition I changed how task
posting works on the DefaultPlatform.
With this implementation the DefaultPlatform keeps one
DefaultForegroundTaskRunner per isolate, plus one
DefaultBackgroundTaskRunner. The DefaultPlatform owns these TaskRunners
with a shared_ptr, which is also shared with any caller of
GetForegroundTaskRunner or GetBackgroundTaskrunner.
This CL moves the task management from the DefaultPlatform to the
TaskRunners. The DefaultForegroundTaskRunner owns and manages the the
task queue, the delayed task queue, and the idle task queue. The
DefaultBackgroundTaskRunner owns the WorkerThread pool and the
background task queue.
In addition changed many Task* to std::unique_ptr<Task> to document task
ownership.
R=rmcilroy@chromium.org
Change-Id: Ib9a01f1f45e5b48844a37d801f884210ec3f6c27
Reviewed-on: https://chromium-review.googlesource.com/753583
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49354}
With this CL, {CreateDefaultPlatform} returns a unique_ptr to indicate
that the caller owns the returned memory. We had several memory leaks
where the memory of the DefaultPlatform did not get deallocated.
In addition, the {TracingController} of the {DefaultPlatform} also gets
received as a unique_ptr. Thereby we document that the {DefaultPlatform}
takes ownership of the {TracingController}. Note that the memory of the
{TracingController} was already owned by the {DefaultPlatform}, but it
was not documented in the interface, and it was used incorrectly in
tests.
This CL fixes the asan issues in
https://chromium-review.googlesource.com/c/v8/v8/+/753583
([platform] Implement TaskRunners in the DefaultPlatform)
R=rmcilroy@chromium.org
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I0d1a6d3b22bb8289dc050b1977e4f58381cec675
Reviewed-on: https://chromium-review.googlesource.com/755033
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49349}
This CL adds a very crude unittest to check that RuntimeCallStats work
correctly with api callbacks present. This currently doesn't check that
all parent timers (namely FunctionCallback) are handled properly.
Drive-by-Fix:
- Use Microseconds for all RCS timer tests
- Add TestWithContext::SetGlobalProperty helper
- Use explicit v8:: prefix in test-utils.{h,cc}
Change-Id: I054e78abca0b87a3b9e07d3b06cccdad15403bae
Reviewed-on: https://chromium-review.googlesource.com/766429
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49348}
This reverts commit f010b28fbe.
Reason for revert: Introduces a clusterfuzz issue and CAnary crash
Original change's description:
> [TurboFan] Diagnostic code to track down bug in representation selection
>
> We need to characterize the types of dead (IrOpcode::kDead) nodes
> introduced in compilation phases prior to representation selection.
> Normally, a dead node isn't expected at the start of this phase. The
> question is, which phase introduced the dead node and failed to
> deal with it properly?
>
> Bug: chromium:780658
> Change-Id: Ief5b45480bb7d704a2d09dafd60b5d389e0fd42e
> Reviewed-on: https://chromium-review.googlesource.com/765968
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Michael Stanton <mvstanton@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49328}
TBR=mvstanton@chromium.org,mstarzinger@chromium.org
Change-Id: I5d628eb1de630ce4a353b6ef0f80fd74ad740f17
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:780658
Reviewed-on: https://chromium-review.googlesource.com/768747
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49347}
We need to characterize the types of dead (IrOpcode::kDead) nodes
introduced in compilation phases prior to representation selection.
Normally, a dead node isn't expected at the start of this phase. The
question is, which phase introduced the dead node and failed to
deal with it properly?
Bug: chromium:780658
Change-Id: Ief5b45480bb7d704a2d09dafd60b5d389e0fd42e
Reviewed-on: https://chromium-review.googlesource.com/765968
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49328}
- Update most callsites to use the new RunJS method
- Update tests to use TestWithNativeContext if possible
- Remove RunJS from test-helpers.cc
- Remove TestWithRandomNumberGenerator from test-utils.h
Change-Id: Ib2a6cc56334dc391ca6a2aeb7780fa324f44f109
Reviewed-on: https://chromium-review.googlesource.com/765373
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49325}
Revert this and its follow-up as suspect for current canary OOM crasher.
This reverts commit 4899bcb66d.
This reverts commit b73ee3344a.
TBR=adamk@chromium.org,hpayer@chromium.org
Bug: chromium:783708
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I4c00582e7ab2df22216ad6732e2843e9958db0c0
Reviewed-on: https://chromium-review.googlesource.com/765447
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49315}
Turn cases where we are multiplying with a power of two into a left shift. We
hit this optimisation roughly 500 times in the snapshot.
Bug:
Change-Id: Ibd3104a3dbe49f247a2d84db94891f6e3a897026
Reviewed-on: https://chromium-review.googlesource.com/763229
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#49306}
MIPS team has recently migrated to @mips.com e-mail address.
Dusan Simicic is no longer part of MIPS V8 team, therefore
his name is removed from OWNERS.
TBR=mstarzinger@chromium.org
NOTRY=true
Bug:
Change-Id: I67fde24a5b9214fa3fca05c0399888b8d18fc699
Reviewed-on: https://chromium-review.googlesource.com/758639
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49299}
- Implement exchangeable timer clock for RuntimeCallStats for testing
- Rewrite RuntimeCAllStatsTest to overwrite the default RCS timer
This gets rid of the previous flakiness for these tests due to using
the real platform timer.
Bug: v8:5677
Change-Id: Iff312c7f79ab97407ba1c0c2c72fb0b35a5efdf1
Reviewed-on: https://chromium-review.googlesource.com/760416
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49285}
This is a reland of 7e78506fc2
Original change's description:
> [Memory] Use OS::Allocate for all OS memory allocations.
>
> - Eliminates OS::ReserveRegion and OS::ReserveAlignedRegion.
> - Changes OS::Allocate to take alignment parameter, reorders parameters
> to match page_allocator.
> - Since the size of memory allocation can be deduced, don't return the
> amount of memory allocated.
> - Changes reservation of aligned address space. Before we would reserve
> (size + alignment) rounded up to page size. This is too much, because
> maximum misalignment is (alignment - page_size).
> - On Windows and Cygwin, we release an oversize allocation and
> immediately retry at the aligned address in the allocation. If we
> lose the address due to a race, we just retry.
> - Clean up all the calls to OS::Allocate in codegen and tests by adding
> helper AllocateSystemPage function (allocation.h) and
> AllocateAssemblerBuffer (cctest.h).
> - Changes 'assm' to 'masm' in some targets for consistency when using
> a macro-assembler.
>
> Bug: chromium:756050
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I306dbe042cc867670fdc935abca29db074b0da71
> Reviewed-on: https://chromium-review.googlesource.com/749848
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49235}
Bug: chromium:756050
Change-Id: I333f7a6aea0bcb608d01cafb43e94893a4625b15
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/758509
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49273}
This reverts commit ac0661b358.
Reason for revert: Clusterfuzz unhappy: chromium:783019 chromium:783035
Original change's description:
> Reland^5 "[turbofan] eagerly prune None types and deadness from the graph"
>
> This gives up on earlier attempts to interpret DeadValue as a signal of
> unreachable code. This does not work because free-floating dead value
> nodes, and even pure branch nodes that use them, can get scheduled so
> early that they get reachable. Instead, we now eagerly remove branches
> that use DeadValue in DeadCodeElimination and replace DeadValue inputs
> to value phi nodes with dummy values.
>
> Reland of https://chromium-review.googlesource.com/715716
>
> Bug: chromium:741225 chromium:776256
> Change-Id: I251efd507c967d4a8882ad8fd2fd96c4185781fe
> Reviewed-on: https://chromium-review.googlesource.com/727893
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49188}
TBR=jarin@chromium.org,tebbi@chromium.org
Bug: chromium:741225 chromium:776256 chromium:783019 chromium:783035
Change-Id: I6a8fa3a08ce2824a858ae01817688e63ed1f442e
Reviewed-on: https://chromium-review.googlesource.com/758770
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49262}
assembler-arm64.h and assembler-arm64-inl.h have a B() function
which conflicts with the B macro in bytecode-utils.h.
Headers that leak macros can be annoying to deal with, in this case
we can't simply undef B at the end of source files that include
bytecode-utils.h because the second source file that includes
bytecode-utils.h won't see the B macro. Let's just move this macro
into the two unittest files that include this header.
Bug: chromium:746958
Change-Id: I588b73fe81615f882a0e010c92ba187d3bc2bf25
Reviewed-on: https://chromium-review.googlesource.com/758779
Commit-Queue: Mostyn Bramley-Moore <mostynb@vewd.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49258}
This reverts commit 7e78506fc2.
Reason for revert: Broke Android build on Arm64.
Original change's description:
> [Memory] Use OS::Allocate for all OS memory allocations.
>
> - Eliminates OS::ReserveRegion and OS::ReserveAlignedRegion.
> - Changes OS::Allocate to take alignment parameter, reorders parameters
> to match page_allocator.
> - Since the size of memory allocation can be deduced, don't return the
> amount of memory allocated.
> - Changes reservation of aligned address space. Before we would reserve
> (size + alignment) rounded up to page size. This is too much, because
> maximum misalignment is (alignment - page_size).
> - On Windows and Cygwin, we release an oversize allocation and
> immediately retry at the aligned address in the allocation. If we
> lose the address due to a race, we just retry.
> - Clean up all the calls to OS::Allocate in codegen and tests by adding
> helper AllocateSystemPage function (allocation.h) and
> AllocateAssemblerBuffer (cctest.h).
> - Changes 'assm' to 'masm' in some targets for consistency when using
> a macro-assembler.
>
> Bug: chromium:756050
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I306dbe042cc867670fdc935abca29db074b0da71
> Reviewed-on: https://chromium-review.googlesource.com/749848
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49235}
TBR=bbudge@chromium.org,hpayer@chromium.org,mlippautz@chromium.org
Change-Id: Ic09de4d63c19746a62e804b1f889817ffaebc330
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:756050
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/758625
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49242}
- Eliminates OS::ReserveRegion and OS::ReserveAlignedRegion.
- Changes OS::Allocate to take alignment parameter, reorders parameters
to match page_allocator.
- Since the size of memory allocation can be deduced, don't return the
amount of memory allocated.
- Changes reservation of aligned address space. Before we would reserve
(size + alignment) rounded up to page size. This is too much, because
maximum misalignment is (alignment - page_size).
- On Windows and Cygwin, we release an oversize allocation and
immediately retry at the aligned address in the allocation. If we
lose the address due to a race, we just retry.
- Clean up all the calls to OS::Allocate in codegen and tests by adding
helper AllocateSystemPage function (allocation.h) and
AllocateAssemblerBuffer (cctest.h).
- Changes 'assm' to 'masm' in some targets for consistency when using
a macro-assembler.
Bug: chromium:756050
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I306dbe042cc867670fdc935abca29db074b0da71
Reviewed-on: https://chromium-review.googlesource.com/749848
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49235}
This is a reland of 34e3e7f91b
Original change's description:
> Introduce gc flag for fuzzing over compaction.
>
> Bug: v8:6972
> Change-Id: If1f4ee04ae00c6ae1e037bbb1ca758e952a8f843
> Reviewed-on: https://chromium-review.googlesource.com/738112
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Commit-Queue: Michał Majewski <majeski@google.com>
> Cr-Commit-Position: refs/heads/master@{#49191}
Bug: v8:6972
Change-Id: I690a72a6d5da17c6f15449b2be4cbb681a67e60e
Reviewed-on: https://chromium-review.googlesource.com/756894
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Michał Majewski <majeski@google.com>
Cr-Commit-Position: refs/heads/master@{#49195}
This gives up on earlier attempts to interpret DeadValue as a signal of
unreachable code. This does not work because free-floating dead value
nodes, and even pure branch nodes that use them, can get scheduled so
early that they get reachable. Instead, we now eagerly remove branches
that use DeadValue in DeadCodeElimination and replace DeadValue inputs
to value phi nodes with dummy values.
Reland of https://chromium-review.googlesource.com/715716
Bug: chromium:741225 chromium:776256
Change-Id: I251efd507c967d4a8882ad8fd2fd96c4185781fe
Reviewed-on: https://chromium-review.googlesource.com/727893
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49188}
This is a reland of 7d231e576a, fixed to
avoid instantiating CountLeadingZeros for bits==0.
Original change's description:
> [bits] Consolidate Count{Leading,Trailing}Zeros
>
> Instead of having one method for 32 bit integers and one for 64 bit,
> plus a templatized version to choose from those two, just implement one
> version which handles unsigned integers of any size. Also, make them
> constexpr.
> The Count{Leading,Trailing}Zeros{32,64} methods are kept for now in
> order to keep the amount of code changes small. Also, sometimes it
> improves readability by stating exactly the size of the argument,
> especially for leading zeros (where zero-extending would add more
> leading zeros).
>
> CountLeadingZeros now uses a binary search inspired implementation
> as proposed in Hacker's Delight. It's more than 20% faster on x64 if
> the builtins are disabled.
> CountTrailingZeros falls back to CountPopulation instead of counting in
> a naive loop. This is ~50% faster.
>
> R=mstarzinger@chromium.org
>
> Change-Id: I1d8bf1d7295b930724163248150444bd17fbb34e
> Reviewed-on: https://chromium-review.googlesource.com/741231
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49106}
Change-Id: Icdff2510ec66d1c96a1912cef29d77d8550994ee
Reviewed-on: https://chromium-review.googlesource.com/753903
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49138}
This reverts commit 7d231e576a.
Reason for revert: Breaks revert for win-clang:
https://build.chromium.org/p/tryserver.chromium.win/builders/win_clang/builds/342755
Original change's description:
> [bits] Consolidate Count{Leading,Trailing}Zeros
>
> Instead of having one method for 32 bit integers and one for 64 bit,
> plus a templatized version to choose from those two, just implement one
> version which handles unsigned integers of any size. Also, make them
> constexpr.
> The Count{Leading,Trailing}Zeros{32,64} methods are kept for now in
> order to keep the amount of code changes small. Also, sometimes it
> improves readability by stating exactly the size of the argument,
> especially for leading zeros (where zero-extending would add more
> leading zeros).
>
> CountLeadingZeros now uses a binary search inspired implementation
> as proposed in Hacker's Delight. It's more than 20% faster on x64 if
> the builtins are disabled.
> CountTrailingZeros falls back to CountPopulation instead of counting in
> a naive loop. This is ~50% faster.
>
> R=mstarzinger@chromium.org
>
> Change-Id: I1d8bf1d7295b930724163248150444bd17fbb34e
> Reviewed-on: https://chromium-review.googlesource.com/741231
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49106}
TBR=mstarzinger@chromium.org,clemensh@chromium.org
Change-Id: Iceeb35bf9c7539a1013c9bdbc47118008611bef2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/753463
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49123}
Instead of having one method for 32 bit integers and one for 64 bit,
plus a templatized version to choose from those two, just implement one
version which handles unsigned integers of any size. Also, make them
constexpr.
The Count{Leading,Trailing}Zeros{32,64} methods are kept for now in
order to keep the amount of code changes small. Also, sometimes it
improves readability by stating exactly the size of the argument,
especially for leading zeros (where zero-extending would add more
leading zeros).
CountLeadingZeros now uses a binary search inspired implementation
as proposed in Hacker's Delight. It's more than 20% faster on x64 if
the builtins are disabled.
CountTrailingZeros falls back to CountPopulation instead of counting in
a naive loop. This is ~50% faster.
R=mstarzinger@chromium.org
Change-Id: I1d8bf1d7295b930724163248150444bd17fbb34e
Reviewed-on: https://chromium-review.googlesource.com/741231
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49106}
This eliminates the AstValue class, effectively moving its
implementation into the Literal AstNode. This should cause
no difference in behavior, but it does signal some shifts
in the underlying system. Biggest changes include:
- Reduction in AST memory usage
- No duplicate HeapNumbers in Ignition constant pools
- Non-String values are allocated either at constant pool
creation time (or at boilerplate creation time for literals),
rather than at AstValueFactory::Internalize() time.
There are a variety of test-only/debug-only changes due to these
switches as well.
Bug: v8:6984
Change-Id: I5f178040ce2796d4e7370c24d1063419e1c843a1
Reviewed-on: https://chromium-review.googlesource.com/731111
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49013}
(This is a reland of cb84b6f624)
This works in the ICs since compiled handlers are not shared anymore.
Bug: chromium:759734
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I3b7d6ae34bb4cfa213f679354fac56fb51bfd5ed
Reviewed-on: https://chromium-review.googlesource.com/739822
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48999}
This reverts commit cb84b6f624.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> [lazy-accessor-pairs] Don't take the fast paths if the context needs to be switched
>
> This works in the ICs since compiled handlers are not shared anymore.
>
> As drive-by cleanup I also removed custom code to deal with compiled handler sharing for primitive and access-checked objects.
>
> Bug: chromium:759734
> Change-Id: Ifb394221c2398f42ea9305acc02845db6004c680
> Reviewed-on: https://chromium-review.googlesource.com/738381
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48979}
TBR=jarin@chromium.org,ishell@chromium.org,verwaest@chromium.org
Change-Id: I9b7424252cbc3f18efd6b6b5b3818651c2863f5c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:759734
Reviewed-on: https://chromium-review.googlesource.com/739487
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48980}
This works in the ICs since compiled handlers are not shared anymore.
As drive-by cleanup I also removed custom code to deal with compiled handler sharing for primitive and access-checked objects.
Bug: chromium:759734
Change-Id: Ifb394221c2398f42ea9305acc02845db6004c680
Reviewed-on: https://chromium-review.googlesource.com/738381
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48979}
Expressions of the form
a_0 + a_1 + a_2 + a_3 + ... + a_n
seem to be reasonably common for cases such as building templates.
However, parsing these expressions results in a n-deep expression tree:
...
/
+
/ \
+ a_2
/ \
a_0 a_1
Traversing this tree during compilation can cause a stack overflow when n is
large.
Instead, for left-associate operations such as add, we now build up an
n-ary node in the parse tree, of the form
n-ary +
/ | \
/ | ... \
a_0 a_1 a_n
The bytecode compiler can now iterate through the child expressions
rather than recursing.
This patch only supports arithmetic operations -- subsequent patches
will enable the same optimization for logical tests and comma
expressions.
Bug: v8:6964
Bug: chromium:724961
Bug: chromium:731861
Bug: chromium:752081
Bug: chromium:771653
Bug: chromium:777302
Change-Id: Ie97e4ce42506fe62a7bc4ffbdaa90a9f698352cb
Reviewed-on: https://chromium-review.googlesource.com/733120
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48920}
Before, the standard way to create a RegList was either:
RegList list = (1 << 0) | (1 << 1) | ...
or
RegList list = rax.bit() | rdx.bit() | ...
The first way allows to make the RegList constexpr, but needs comments
to document which registers you are referring to, and it has no checks
that all bits you set on the RegList actually belong to valid registers.
The second one uses the symbolic names, hence is much more readable and
makes it harder to construct invalid RegLists. It's not constexpr
though, since the {bit()} method on the register types is not constexpr.
This CL adds a constexpr accessor to get the code and bit of a
constexpr Register, and adds a helper method to create a constexpr
RegList like this:
constexpr RegList list = Register::ListOf<rax, rdx, rdi>();
This new method is used in a number of places to test its
applicability. Other uses of the old pattern remain and can be cleaned
up later.
R=tebbi@chromium.org
Change-Id: Ie7b1d6342dc5f316dcfedd0363b3540ad5e7f413
Reviewed-on: https://chromium-review.googlesource.com/728026
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48887}
This removes all but one caller of Literal::raw_value(), thus
hiding AstValue from the rest of the codebase. This is in
preparation to move much of AstValue's implementation up
into Literal itself, thus avoiding the overhead of the
underling ZoneObjects and allowing us to remove complexity
such as the cache of Smi-valued AstValues.
Bug: v8:6984
Change-Id: I1b90aa64b9d26db36ef486afe73cda4473ef866e
Reviewed-on: https://chromium-review.googlesource.com/731109
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48884}
Also removes can_execute_on_background_thread() since all compilation jobs can now do that.
Part of the work towards enabling off-thread bytecode compilation.
BUG=v8:5203
Change-Id: I6a52c26d599ce74482b5fb49926603cb326f1e31
Reviewed-on: https://chromium-review.googlesource.com/731285
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48826}
This adds a new InstanceOfIC where the TestInstanceOf bytecode collects
constant feedback about the right-hand side of instanceof operators,
including both JSFunction and JSBoundFunction instances. TurboFan then
uses the feedback to optimize instanceof in places where the right-hand
side is not a known constant (known to TurboFan).
This addresses the odd performance cliff that we see with instanceof in
functions with multiple closures. It was discovered as one of the main
bottlenecks on the uglify-es test in the web-tooling-benchmark. The
uglify-es test (run in separation) is ~18% faster with this change.
On the micro-benchmark in the tracking bug we go from
instanceofSingleClosure_Const: 69 ms.
instanceofSingleClosure_Class: 246 ms.
instanceofMultiClosure: 246 ms.
instanceofParameter: 246 ms.
to
instanceofSingleClosure_Const: 70 ms.
instanceofSingleClosure_Class: 75 ms.
instanceofMultiClosure: 76 ms.
instanceofParameter: 73 ms.
boosting performance by roughly 3.6x and thus effectively removing the
performance cliff around instanceof.
Bug: v8:6936, v8:6971
Change-Id: Ib88dbb9eaef9cafa4a0e260fbbde73427a54046e
Reviewed-on: https://chromium-review.googlesource.com/730686
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48820}
Whitespace-only strings count as empty too.
This behavior is different from BigInt.parseInt(""),
which throws a SyntaxError.
Bug: v8:6791, v8:6957
Change-Id: I6671c803f3ba83e23c3e0cad81d3af29dba61c9f
Reviewed-on: https://chromium-review.googlesource.com/727301
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48797}
JSClassOf may lower to a call to a builtin, and needs to be
modeled in a way that the effect chain can be maintained.
Bug: v8:6929
Change-Id: Ida332e6d85e2eb8b33fcad810d195ef3e897ccb0
Reviewed-on: https://chromium-review.googlesource.com/727204
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48786}
This allocates and populates potential source position table before the
underlying {Code} objects is allocated. It essentially makes the field
holding said table immutable after allocation.
R=verwaest@chromium.org
BUG=v8:6792
Change-Id: If35462688a1b502f28ae84f73b82b5df5005735f
Reviewed-on: https://chromium-review.googlesource.com/727895
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48781}
The wasm memory deserialization didn't properly increment the object id, so
wouldn't work properly if the memory object (or its contained
SharedArrayBuffer) where included multiple times in the object.
Bug: v8:6895
Change-Id: I5c4c25bad2ec6152883c5a7321038aba1950480a
Reviewed-on: https://chromium-review.googlesource.com/721630
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48767}
Moves the feedback vector slot allocation out of ast-numbering and into
bytecode generation directly. This has a couple of benifits, including reduced
AST size, avoid code duplication and reduced feedback vector sizes in many cases
due to only allocating slots when needed. Also removes AstProperties since
this is no longer needed.
AstNumbering is now only used to allocate suspend ids for generators.
BUG=v8:6921
Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f
Reviewed-on: https://chromium-review.googlesource.com/722959
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48757}
This also changes modulo to be more like others, e.g., Pow:
- have an inline Modulo
- have a modulo_double_double that we can use as FUNCTION_ADDR in assembler.cc
Bug:
Change-Id: Id360e4adcde5712ffc5ac22abd3bbaab6aec09f5
Reviewed-on: https://chromium-review.googlesource.com/728027
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48747}
Because the toboolean operator may lower to a builtin call (which is
effectful in turbofan parlance after effect control linearization),
it really should be encoded as a simplified operator, which can
be optimized with respect for the effect chain in linearization.
No new functionality here, rather a furniture rearrangement in
the TurboFan node structure.
Bug: v8:6929
Change-Id: I371fd22941397d5c28d13bded2738161d8da8275
Reviewed-on: https://chromium-review.googlesource.com/725721
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48727}
This patch provides "Abstract Comparison" functions on the BigInt
class for comparing BigInts to Numbers and Strings.
The functionality is not exposed to JavaScript yet.
Bug: v8:6791
Change-Id: I835f290203a31f363970b1edb359e19af6dabc5d
Reviewed-on: https://chromium-review.googlesource.com/722324
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48718}
This reverts commit d607f1e72d.
Reason for revert: Suspected cause of hanging tests:
https://bugs.chromium.org/p/v8/issues/detail?id=6927#c13
Original change's description:
> [Memory] Move GetRandomMmapAddr from base::OS platform to v8::internal.
>
> - Moves GetRandomMmapAddr from platform to v8::internal allocation
> primitives, in preparation for delegating this to the embedder.
> - Adds hint parameters to OS functions that used to use this function.
>
> Bug: chromium:756050
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: Iad72e6eac9c08a3e22c2cd2b2905623b8e514ae0
> Reviewed-on: https://chromium-review.googlesource.com/677777
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48124}
TBR=bbudge@chromium.org,ulan@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:756050
Change-Id: I2c515934906e67b47ceea2863bc2992ac1d23ab3
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/726319
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48701}
This makes the function constexpr and implements it for arbitrary
unsigned integer types (up to 64 bits, but this can be extended if
needed).
R=mstarzinger@chromium.org
Bug: v8:6600, v8:6921
Change-Id: I86d427238fadd55abb5a27f31ed648d4b02fc358
Reviewed-on: https://chromium-review.googlesource.com/718457
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48696}
We didn't correctly maintain the effect chain between the load of
the map and the load of the instance type from the map.
Bug: v8:6929
Change-Id: I970709fe74483c5cdef3d0cea36bb9e1dc98b40e
Reviewed-on: https://chromium-review.googlesource.com/725424
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48690}
This CL fixes all occurences that don't require special OWNER reviews,
or can be reviewed by Michi.
After this one, we should be able to reenable the readability/check
cpplint check.
R=mstarzinger@chromium.org
Bug: v8:6837, v8:6921
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Ic81d68d5534eaa795b7197fed5c41ed158361d62
Reviewed-on: https://chromium-review.googlesource.com/721120
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48670}
Because the typeof operator may lower to a builtin call (which is
effectful in turbofan parlance after effect control linearization),
it really should be encoded as a simplified operator, which can
be optimized with respect for the effect chain in linearization.
No new functionality here, rather a furniture rearrangement in
the TurboFan node structure.
BUG=v8:6929
Change-Id: I38593e10956ebd57cecdd606c35f3f73efb1327e
Reviewed-on: https://chromium-review.googlesource.com/718745
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48613}
Calls like read_leb<int32_t, true, true, true>(...) can be hard to read
and understand. This CL replaces the three boolean template parameters
with enums so that the call is read_leb<int32_t, kChecked, kAdvancePC, kTrace>(...)
now.
R=clemensh@chromium.org
Bug: v8:6921
Change-Id: Id876a727d5e17df721444e7e5a117ad5395071aa
Reviewed-on: https://chromium-review.googlesource.com/718204
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48607}
Reuses the existing logic for BigInt.parseInt, adapted slightly
to allow octal and binary radix prefixes (and to support parsing
of a raw character buffer, rather than a v8::internal::String).
Bug: v8:6791
Change-Id: I41904b2204721eac452e0765fa9ff0ab26ee343b
Reviewed-on: https://chromium-review.googlesource.com/711334
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48560}
This flag describes that the memory defined in a wasm module has a
maximum size. Therefore I think kHasMaximumFlag is more appropriate.
R=titzer@chromium.org
Bug: v8:6921
Change-Id: Ie794d670f74e7f1f9a42822e2f774da85aaaaa4b
Reviewed-on: https://chromium-review.googlesource.com/718198
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48517}
This is a reland of cc237d872b
Original change's description:
> Reland "[wasm] trap handlers: fall back on old signal handler"
>
> This is a reland of ee4fe8963c
> Original change's description:
> > [wasm] trap handlers: fall back on old signal handler
> >
> > This is primarily needed to test D8 under ASan. ASan installs a signal handler
> > early in the process startup to show stack traces from crashes. We need to make
> > sure that if V8 does not handle a signal then the existing handler gets a
> > chance.
> >
> > This change only applies when using V8's default signal handler. When
> > integrating with the embedder's signal handler the behavior is unchanged.
> >
> > Bug: chromium:771948
> > Change-Id: Ifd560acf9700ec5f714f009530258fa92c83cabe
> > Reviewed-on: https://chromium-review.googlesource.com/705823
> > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> > Commit-Queue: Eric Holk <eholk@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#48429}
>
> Bug: chromium:771948
> Change-Id: Ide307091c432fd933c48f89c51851b8dce44dd30
> Reviewed-on: https://chromium-review.googlesource.com/710114
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Eric Holk <eholk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48435}
Bug: chromium:771948
Change-Id: I781dfe356a728760090b6ccfa58212096e8f20c8
Reviewed-on: https://chromium-review.googlesource.com/713956
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48474}
Only change over original: Init sig_index to 0 at
function-body-decoder-impl.h:168, to make MSAN happy on error path.
R=titzer@chromium.org
Change-Id: I9ac17215360523b656b10d2466201001b65992c0
Reviewed-on: https://chromium-review.googlesource.com/712655
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Rossberg <rossberg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48463}
This introduces a ToNumeric conversion to the runtime and interpreter.
ToNumeric behaves like ToNumber, except that it also lets BigInts pass.
Bug: v8:6791
Change-Id: Idf9d0b5d283638459fe5893de41cc120356247a7
Reviewed-on: https://chromium-review.googlesource.com/707013
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48440}
This reverts commit cc237d872b.
Reason for revert: breaks win clang:
https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20clang/builds/8538
Original change's description:
> Reland "[wasm] trap handlers: fall back on old signal handler"
>
> This is a reland of ee4fe8963c
> Original change's description:
> > [wasm] trap handlers: fall back on old signal handler
> >
> > This is primarily needed to test D8 under ASan. ASan installs a signal handler
> > early in the process startup to show stack traces from crashes. We need to make
> > sure that if V8 does not handle a signal then the existing handler gets a
> > chance.
> >
> > This change only applies when using V8's default signal handler. When
> > integrating with the embedder's signal handler the behavior is unchanged.
> >
> > Bug: chromium:771948
> > Change-Id: Ifd560acf9700ec5f714f009530258fa92c83cabe
> > Reviewed-on: https://chromium-review.googlesource.com/705823
> > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> > Commit-Queue: Eric Holk <eholk@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#48429}
>
> Bug: chromium:771948
> Change-Id: Ide307091c432fd933c48f89c51851b8dce44dd30
> Reviewed-on: https://chromium-review.googlesource.com/710114
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Eric Holk <eholk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48435}
TBR=mseaborn@chromium.org,bradnelson@chromium.org,gdeepti@chromium.org,eholk@chromium.org,mark@chromium.org
Change-Id: If71f61ae186fc6be2006edeb2dffd7e2b6827d91
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:771948
Reviewed-on: https://chromium-review.googlesource.com/711854
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48436}
This is a reland of ee4fe8963c
Original change's description:
> [wasm] trap handlers: fall back on old signal handler
>
> This is primarily needed to test D8 under ASan. ASan installs a signal handler
> early in the process startup to show stack traces from crashes. We need to make
> sure that if V8 does not handle a signal then the existing handler gets a
> chance.
>
> This change only applies when using V8's default signal handler. When
> integrating with the embedder's signal handler the behavior is unchanged.
>
> Bug: chromium:771948
> Change-Id: Ifd560acf9700ec5f714f009530258fa92c83cabe
> Reviewed-on: https://chromium-review.googlesource.com/705823
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Eric Holk <eholk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48429}
Bug: chromium:771948
Change-Id: Ide307091c432fd933c48f89c51851b8dce44dd30
Reviewed-on: https://chromium-review.googlesource.com/710114
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48435}
This reverts commit ee4fe8963c.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> [wasm] trap handlers: fall back on old signal handler
>
> This is primarily needed to test D8 under ASan. ASan installs a signal handler
> early in the process startup to show stack traces from crashes. We need to make
> sure that if V8 does not handle a signal then the existing handler gets a
> chance.
>
> This change only applies when using V8's default signal handler. When
> integrating with the embedder's signal handler the behavior is unchanged.
>
> Bug: chromium:771948
> Change-Id: Ifd560acf9700ec5f714f009530258fa92c83cabe
> Reviewed-on: https://chromium-review.googlesource.com/705823
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Eric Holk <eholk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48429}
TBR=mseaborn@chromium.org,bradnelson@chromium.org,gdeepti@chromium.org,eholk@chromium.org,mark@chromium.org
Change-Id: Ib43b096831b15c312b3b460e59f268d5ea903f21
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:771948
Reviewed-on: https://chromium-review.googlesource.com/710034
Reviewed-by: Eric Holk <eholk@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48430}
This is primarily needed to test D8 under ASan. ASan installs a signal handler
early in the process startup to show stack traces from crashes. We need to make
sure that if V8 does not handle a signal then the existing handler gets a
chance.
This change only applies when using V8's default signal handler. When
integrating with the embedder's signal handler the behavior is unchanged.
Bug: chromium:771948
Change-Id: Ifd560acf9700ec5f714f009530258fa92c83cabe
Reviewed-on: https://chromium-review.googlesource.com/705823
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48429}
When hitting objects that are allocated in the most recent lienar
allocation area, the concurrent marker currently has to bail out to the
main thread.
However, we only have to delay processing those objects until we are at
a safepoint, e.g. IM::Step(). With this change we flush those
on-hold-objects back to the shared queue upon performing an incremental
marking step.
Bug: chromium:694255
Change-Id: I25647d0fc581a5c4de0346bc394dc51062f65f70
Reviewed-on: https://chromium-review.googlesource.com/707315
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48424}
At the moment we check only in the module-decoder if the sections in a
module appear at most once. The code section, however, we process
already before this check. With this CL we check that there is at most
one code section before we start processing it.
R=clemensh@chromium.org
TEST=WasmStreamingDecoderTest.TwoCodeSections
Bug: chromium:771916
Change-Id: Icc79d5a87ab39f450a35c688f74ea5e67cae4b3c
Reviewed-on: https://chromium-review.googlesource.com/702379
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48314}
Verify that both UTF-8 decoders (incremental and non-incremental one) match the
expectations.
Also cleanup / harden the UTF-8 handling code, as suggested in
https://chromium-review.googlesource.com/c/v8/v8/+/671020/ .
BUG=chromium:765608
Change-Id: I6344d62ca15b75ac8e333421c94c4aa35ab8190d
Reviewed-on: https://chromium-review.googlesource.com/681217
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48229}
Removes script() from CompilationInfo since it might not be created when
compiling from a background thread.
BUG=v8:5203
Change-Id: Ic36fd04cf4792336707b2d3715d47c59b6a97faf
Reviewed-on: https://chromium-review.googlesource.com/690299
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48220}
Merge better captures the upcoming usecase in the wasm native heap,
where allocating/freeing is moving the accounting of memory from
a free list to an allocated list and vice-versa - making 'Release'
an odd API when allocating.
Bug:
Change-Id: I9010959c91a1e8585eb06303ab06078132a03f60
Reviewed-on: https://chromium-review.googlesource.com/688004
Reviewed-by: Eric Holk <eholk@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48211}
The WasmContext struct introduced in this CL is used to store the
mem_size and mem_start address of the wasm memory. These variables can
be accessed at C++ level at graph build time (e.g., initialized during
instance building). When the GrowMemory runtime is invoked, the context
variables can be changed in the WasmContext at C++ level so that the
generated code will load the correct values.
This requires to insert a relocatable pointer only in the
JSToWasmWrapper (and in the other wasm entry points), the value is then
passed from function to function as an automatically added additional
parameter. The WasmContext is then dropped when creating an Interpreter
Entry or when invoking a JavaScript function. This removes the need of
patching the generated code at runtime (i.e., when the memory grows)
with respect to WASM_MEMORY_REFERENCE and WASM_MEMORY_SIZE_REFERENCE.
However, we still need to patch the code at instance build time to patch
the JSToWasmWrappers; in fact the address of the WasmContext is not
known during compilation, but only when the instance is built.
The WasmContext address is passed as the first parameter. This has the
advantage of not having to move the WasmContext around if the function
does not use many registers. This CL also changes the wasm calling
convention so that the first parameter register is different from the
return value register. The WasmContext is attached to every
WasmMemoryObject, to share the same context with multiple instances
sharing the same memory. Moreover, the nodes representing the
WasmContext variables are cached in the SSA environment, similarly to
other local variables that might change during execution. The nodes are
created when initializing the SSA environment and refreshed every time a
grow_memory or a function call happens, so that we are sure that they
always represent the correct mem_size and mem_start variables.
This CL also removes the WasmMemorySize runtime (since it's now possible
to directly retrieve mem_size from the context) and simplifies the
GrowMemory runtime (since every instance now has a memory_object).
R=ahaas@chromium.org,clemensh@chromium.org
CC=gdeepti@chromium.org
Change-Id: I3f058e641284f5a1bbbfc35a64c88da6ff08e240
Reviewed-on: https://chromium-review.googlesource.com/671008
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48209}
The members of HandleScopeImplementer are copied with memcpy when
the isolate is transferred to another thread. List contained some
primitives which allowed us to manually free the backing store, which
was needed in order to ensure that threads would not hold on to
old pointers and use them later. With std::vector, we can't do that.
Here we change the HandleScopeImplementer to instead use a custom
structure DetachableVector, which contains a std::vector but allows
manual detaching and freeing of the backing store. This allows us to
maintain the old behavior.
Bug: v8:6333
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I6361d161cdb19878ba19ed51d6ba2fae99e8cdc0
Reviewed-on: https://chromium-review.googlesource.com/660125
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48197}
This is a second attempt at landing CL 644866 which was reverted by
CL 667019.
Extends the current implementation of WASM exceptions to be able to
throw exceptions with values (not just tags).
A JS typed (uint_16) array is used to hold the thrown values. This
allows all WASM types to be stored (i32, i64, f32, and f64) as well as
be inspected in JS.
The previous CL was reverted because the WASM compiler made calls to
run time functions with tagged objects, which must not be done. To fix
this, all run time calls use the thread-level isolate to hold the
exception being processed.
Bug: v8:6577
Change-Id: I4b1ef7e2847b71a2fab8e9934a0531057db9de63
Reviewed-on: https://chromium-review.googlesource.com/677056
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48148}
When inlining based on SharedFunctionInfo rather than based on concrete
JSFunction, we weren't able to properly optimize array, object and
regexp literals inside the inlinee, because we didn't know the concrete
FeedbackVector for the inlinee inside JSCreateLowering. This was because
JSCreateLowering wasn't properly updated after the literals moved to the
FeedbackVector. Now with this CL we also have the VectorSlotPair on the
literal creation operators, just like we do for property accesses and
calls, and are thus able to always access the appropriate FeedbackVector
and optimize the literal creation.
The impact is illustrated by the micro-benchmark on the tracking bug,
which goes from
createEmptyArrayLiteral: 1846 ms.
createShallowArrayLiteral: 1868 ms.
createShallowObjectLiteral: 2246 ms.
to
createEmptyArrayLiteral: 1175 ms.
createShallowArrayLiteral: 1187 ms.
createShallowObjectLiteral: 1195 ms.
with this CL, so up to 2x faster now.
Drive-by-fix: Also remove the unused CreateEmptyObjectLiteral builtin
and cleanup the names of the other builtins to be consistent with the
names of the TurboFan operators and Ignition bytecodes.
Bug: v8:6856
Change-Id: I453828d019b27c9aa1344edac0dd84e91a457097
Reviewed-on: https://chromium-review.googlesource.com/680656
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48140}
Use the (D)CHECK_{EQ,NE,GT,...} macros instead of (D)CHECK with an
embedded comparison. This gives better error messages and also does the
right comparison for signed/unsigned mismatches.
This will allow us to reenable the readability/check cpplint check.
R=jarin@chromium.org
Bug: v8:6837
Change-Id: I712580c2a4326e06ee3d6d0eb4ff8c7d24f5fdb9
Reviewed-on: https://chromium-review.googlesource.com/671227
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48135}
Tagged templates were previously desugared during parsing using some
combination of runtime support written in JavaScript and C++, which
prevented some optimizations from happening, namely the constant folding
of the template object in TurboFan optimized code. This CL adds a new
bytecode GetTemplateObject (with a corresponding GetTemplateObject AST
node), which represents the abstract operation in the ES6 specification
and allows TurboFan to simply constant-fold template objects at compile
time (which is explicitly supported by the specification).
This also pays down some technical debt by removing the template.js
runtime support and therefore should reduce the size of the native
context (snapshot) a bit.
With this change in-place the ES6 version microbenchmark in the
referenced tracking bug is now faster than the transpiled Babel
code, it goes from
templateStringTagES5: 4552 ms.
templateStringTagES6: 14185 ms.
templateStringTagBabel: 7626 ms.
to
templateStringTagES5: 4515 ms.
templateStringTagES6: 7491 ms.
templateStringTagBabel: 7639 ms.
which corresponds to a solid 45% reduction in execution time. With some
further optimizations the ES6 version should be able to outperform the
ES5 version. This micro-benchmark should be fairly representative of the
six-speed-templatestringtag-es6 benchmark, and as such that benchmark
should also improve by around 50%.
Bug: v8:6819,v8:6820
Tbr: mlippautz@chromium.org
Change-Id: I821085e3794717fc7f52b5c306fcb93ba03345dc
Reviewed-on: https://chromium-review.googlesource.com/677462
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48126}
- Moves GetRandomMmapAddr from platform to v8::internal allocation
primitives, in preparation for delegating this to the embedder.
- Adds hint parameters to OS functions that used to use this function.
Bug: chromium:756050
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Iad72e6eac9c08a3e22c2cd2b2905623b8e514ae0
Reviewed-on: https://chromium-review.googlesource.com/677777
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48124}
In the current implementation, compilation would fail because
operator<< is not defined for enum classes. For others, the compiler
finds more than one operator<<, so it fails because it's ambiguous.
This CL fixes this by printing the integer value for enums, uses the
operator<< for all values that support it, and prints "<unprintable>"
otherwise.
Also, lots of unit tests.
R=ishell@chromium.org
Bug: v8:6837
Change-Id: I895ed226672aa07213f9605e094b87af186ec2e4
Reviewed-on: https://chromium-review.googlesource.com/671016
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48110}
And add some tests for (seemingly) previously uncovered cases.
The additional check for unreachable code is not needed any more, since
polymorphic stack values get assigned a specific type on their first
use or validation anyway. Hence the first entry in the br_table will
assign specific types to all polymorphic stack values, and type checking
will fail if later entries do not match.
R=rossberg@chromium.orgCC=titzer@chromium.org
Change-Id: I1d0f91f927a2aa5186f874112e91ebffa1f1b3a7
Reviewed-on: https://chromium-review.googlesource.com/675405
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48109}
Removes
- SequentialMarkingDeque
- The ability to handle marking deque overflow
- BlackToGrey transitions
We switched to a different marking work list on M61 that fails
in OOM upon failing to allocate Segments used in the work list.
Bug: chromium:758570
Change-Id: I66e2ab912271bf84b085dccc9b4bdd96076b64fb
Reviewed-on: https://chromium-review.googlesource.com/632676
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48078}
This reverts commit ee5c31f335.
Reason for revert: Fixed compiler failure
Original change's description:
> Revert "[wasm] A simple allocator datastructure for off-the heap"
>
> This reverts commit 110d9ab005.
>
> Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607
>
> Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different?
>
> Original change's description:
> > [wasm] A simple allocator datastructure for off-the heap
> >
> > We'll use this allocator in a follow-up CL to:
> > - allocate speculative sizes of memory for a module that's being
> > compiled (e.g. 2*size of wasm code).
> > - each module will own such a sub-pool, and then use it to allocate
> > contiguous chunks of memory for code.
> >
> > The underlying assumptions for the chosen allocation strategy is that:
> > - the allocation granularity for pools is 1 page, so that no one page
> > is owned by more than one wasm module
> > - typical pool sizes (given module sizes) are multiple pages.
> > - modules and module instances are typically few and long lived. Typically,
> > we expect one module and one instance.
> >
> > This means we shouldn't expect fragmentations that lead to code being
> > non-allocatable, or prohibitively many ranges.
> >
> > The data structure just manages ranges of addresses. Virtual memory management
> > will be separate, as part of the responsibility of a "WasmHeap"
> > that will be introduced in the future. So will concurrency control.
> >
> > Bug:
> > Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39
> > Reviewed-on: https://chromium-review.googlesource.com/669296
> > Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> > Reviewed-by: Eric Holk <eholk@chromium.org>
> > Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#48053}
>
> TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org
>
> Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://chromium-review.googlesource.com/670141
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48054}
TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org
Change-Id: Ib6a7a3e6098d2689e60cdca85ec77e57e5295e48
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/670142
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48055}
This reverts commit 110d9ab005.
Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607
Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different?
Original change's description:
> [wasm] A simple allocator datastructure for off-the heap
>
> We'll use this allocator in a follow-up CL to:
> - allocate speculative sizes of memory for a module that's being
> compiled (e.g. 2*size of wasm code).
> - each module will own such a sub-pool, and then use it to allocate
> contiguous chunks of memory for code.
>
> The underlying assumptions for the chosen allocation strategy is that:
> - the allocation granularity for pools is 1 page, so that no one page
> is owned by more than one wasm module
> - typical pool sizes (given module sizes) are multiple pages.
> - modules and module instances are typically few and long lived. Typically,
> we expect one module and one instance.
>
> This means we shouldn't expect fragmentations that lead to code being
> non-allocatable, or prohibitively many ranges.
>
> The data structure just manages ranges of addresses. Virtual memory management
> will be separate, as part of the responsibility of a "WasmHeap"
> that will be introduced in the future. So will concurrency control.
>
> Bug:
> Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39
> Reviewed-on: https://chromium-review.googlesource.com/669296
> Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> Reviewed-by: Eric Holk <eholk@chromium.org>
> Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48053}
TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org
Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/670141
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48054}
We'll use this allocator in a follow-up CL to:
- allocate speculative sizes of memory for a module that's being
compiled (e.g. 2*size of wasm code).
- each module will own such a sub-pool, and then use it to allocate
contiguous chunks of memory for code.
The underlying assumptions for the chosen allocation strategy is that:
- the allocation granularity for pools is 1 page, so that no one page
is owned by more than one wasm module
- typical pool sizes (given module sizes) are multiple pages.
- modules and module instances are typically few and long lived. Typically,
we expect one module and one instance.
This means we shouldn't expect fragmentations that lead to code being
non-allocatable, or prohibitively many ranges.
The data structure just manages ranges of addresses. Virtual memory management
will be separate, as part of the responsibility of a "WasmHeap"
that will be introduced in the future. So will concurrency control.
Bug:
Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39
Reviewed-on: https://chromium-review.googlesource.com/669296
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48053}
This reverts commit 7b5a40222e.
Reason for revert: GC stress-test failures exposed by 7742e534a8https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15110/steps/Mjsunit/logs/exceptions
Original change's description:
> Add capability of throwing values in WASM
>
> Extends the current implementation of WASM exceptions to be able to
> throw exceptions with values (not just tags).
>
> An JS typed array (uint_16) is used to hold thrown values, so that the
> thrown values can be inspected in JS.
>
> Bug: v8:6577
> Change-Id: I1007e79ceaffd64386b62562919cfbb920fc10c5
> Reviewed-on: https://chromium-review.googlesource.com/633866
> Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Eric Holk <eholk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48001}
TBR=bbudge@chromium.org,mtrofin@chromium.org,eholk@chromium.org,clemensh@chromium.org,kschimpf@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:6577
Change-Id: I8f545183c2d2abb1bf4a0b3ee23379f3754ffd55
Reviewed-on: https://chromium-review.googlesource.com/667019
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48050}
In this CL I implement streaming compilation for WebAssembly,
as described in the design doc I have sent out already.
In this implementation the decoding of sections other than the
code section is done immediately on the foreground thread.
Eventually all decoding should happen in the background. I
think it is acceptable to do the decoding on the foreground
thread for now because I have finished it already, and
decoding in the background would add even more complexity to
this CL.
Bug:v8:6785
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I285e1e5e1a5a243113c92571b25ee9bae551d0ed
Reviewed-on: https://chromium-review.googlesource.com/631721
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48022}
Extends the current implementation of WASM exceptions to be able to
throw exceptions with values (not just tags).
An JS typed array (uint_16) is used to hold thrown values, so that the
thrown values can be inspected in JS.
Bug: v8:6577
Change-Id: I1007e79ceaffd64386b62562919cfbb920fc10c5
Reviewed-on: https://chromium-review.googlesource.com/633866
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48001}
This continues to move the "desugaring" of unary operators further
down the pipeline, in this case into the bytecode handlers for new
bytecodes `Negate` and `BitwiseNot` and the corresponding TF code
in BytecodeGraphBuilder.
Bug: v8:6971
Tbr: yangguo@chromium.org
Change-Id: If6b5d6b239a09ef8b4dbde49321614503c0f5beb
Reviewed-on: https://chromium-review.googlesource.com/661146
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47980}
As part of that change, make ToNumber return in the accumulator.
Bug: v8:6791
Change-Id: I8ce0f4fbc7ad8ee7fb4a32a8a499394395010750
Reviewed-on: https://chromium-review.googlesource.com/658082
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47976}
