Reason for revert:
problems on Mac64
Original issue's description:
> [turbofan] Add the StackSlot operator to turbofan.
>
> The StackSlot operator allows to allocate a spill slot on the stack. We
> are going to use this operator to pass floats through pointers to c
> functions, which we need for floating point rounding in the case where
> the architecture does not provide rounding instructions.
>
> R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-ppc-ports@googlegroups.com, v8-mips-ports@googlegroups.com
>
> Committed: https://crrev.com/7a693437787090d62d937b862e29521debcc5223
> Cr-Commit-Position: refs/heads/master@{#33600}
TBR=titzer@chromium.org,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,v8-ppc-ports@googlegroups.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1644283002
Cr-Commit-Position: refs/heads/master@{#33601}
So far the for-in slow path in Crankshaft unconditionally called
%ForInFilter for every iteration of the for-in loop, without paying
attention to the possible enum cache equipped receiver map. So even
though we iterate the enum cache FixedArray associated with the map
we don't check the map, but always go to %ForInFilter. This would be
perfectly fine if the enum cache FixedArray would be immutable, but
due to some funny GC/runtime interaction kicking in, the enum cache
can be right trimmed while we are iterating it, and the only way to
detect this is to ensure that we check the map when accessing the
enum cache.
BUG=v8:3650,v8:4715
LOG=n
Review URL: https://codereview.chromium.org/1650493002
Cr-Commit-Position: refs/heads/master@{#33599}
This is to fix a bug in the bytecode graph builder. This cl adds a new merge
node before we copy the environment on conditional/unconditional jumps. Since
these environments could be merged later, we add a place holder merge so that
the control dependencies are correctly merged. If we do not have a merge node
we may incorrectly merge the dependencies into the previous block.
For ex: test-run-variables/ContextStoreVariables in cctests.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1641143002
Cr-Commit-Position: refs/heads/master@{#33591}
avoid jump threading erasing the reconstruction of a frame, if the
frame was elided.
BUG=
Review URL: https://codereview.chromium.org/1642823002
Cr-Commit-Position: refs/heads/master@{#33590}
ES2015 Annex B.1.4 specifies a restricted pattern language for unicode
mode. This change reflects that, based on some test262 test cases.
R=littledan@chromium.org
BUG=v8:2952
LOG=N
Review URL: https://codereview.chromium.org/1645573002
Cr-Commit-Position: refs/heads/master@{#33584}
Reason for revert:
Revert patch due to a number of failures appearing on the MIPS v8 simulator
Original issue's description:
> MIPS: Add FPXX support to MIPS32R2
>
> The JIT code generated by V8 is FPXX compliant
> when v8 compiled with FPXX flag. This allows the code to
> run in both FP=1 and FP=0 mode. It also alows v8 to be used
> as a library by both FP32 and FP64 binaries.
>
> BUG=
>
> Committed: https://crrev.com/95110dde666158a230a823fd50a68558ad772320
> Cr-Commit-Position: refs/heads/master@{#33576}
TBR=paul.lind@imgtec.com,gergely.kis@imgtec.com,akos.palfi@imgtec.com,ilija.pavlovic@imgtec.com,marija.antic@imgtec.com,miran.karic@imgtec.com,balazs.kilvady@imgtec.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1646813003
Cr-Commit-Position: refs/heads/master@{#33583}
The previous versions of Math.max and Math.min made it difficult to
optimize those (that's why we already have custom code in Crankshaft),
and due to lack of ideas what to do about the variable number of
arguments, we will probably need to stick in special code in TurboFan
as well; so inlining those builtins is off the table, hence there's no
real advantage in having them around as "not quite JS" with extra work
necessary in the optimizing compilers to still make those builtins
somewhat fast in cases where we cannot inline them (also there's a
tricky deopt loop in Crankshaft related to Math.min and Math.max, but
that will be dealt with later).
So to sum up: Instead of trying to make Math.max and Math.min semi-fast
in the optimizing compilers with weird work-arounds support %_Arguments
%_ArgumentsLength, we do provide the optimal code as native builtins
instead and call it a day (which gives a nice performance boost on some
benchmarks).
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1641083003
Cr-Commit-Position: refs/heads/master@{#33582}
This translates the exception handler table attached to a bytecode array
correctly into exceptional projections within the TurboFan graph. We
perform an abstract simulation of handlers that are being entered and
exited by the bytecode iteration to track the correct handler for each
node.
R=oth@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1641723002
Cr-Commit-Position: refs/heads/master@{#33580}
This change adds AbstractCode, which can be either Code or
BytecodeArray, and adds methods to calculate source position based
on that. Also cleans up to use code offsets instead of raw PC
where possible, and consistently uses the offset from instruction
start (as opposed to code object start).
R=rmcilroy@chromium.org, vogelheim@chromium.org
BUG=v8:4690
LOG=N
Review URL: https://codereview.chromium.org/1618343002
Cr-Commit-Position: refs/heads/master@{#33579}
The JIT code generated by V8 is FPXX compliant
when v8 compiled with FPXX flag. This allows the code to
run in both FP=1 and FP=0 mode. It also alows v8 to be used
as a library by both FP32 and FP64 binaries.
BUG=
Review URL: https://codereview.chromium.org/1586223004
Cr-Commit-Position: refs/heads/master@{#33576}
The body of a generator function can now refer to the generator's input value via a new
"function.sent" expression. We extend the proposal at
https://github.com/allenwb/ESideas/blob/master/Generator%20metaproperty.md
in the obvious way to also apply to GeneratorResumeAbrupt.
This will enable us to desugar yield*.
The new syntax is behind a new --harmony-function-sent flag.
BUG=v8:4700
LOG=n
Review URL: https://codereview.chromium.org/1620253003
Cr-Commit-Position: refs/heads/master@{#33574}
Note that in these cases, we don't support computed property names yet, just
as we don't for object and class literals.
BUG=v8:3699, v8:4710
LOG=n
Review URL: https://codereview.chromium.org/1634403002
Cr-Commit-Position: refs/heads/master@{#33562}
Reason for revert:
Bug: failing to use write barrier when writing code entry into closure.
Original issue's description:
> Reland of Type Feedback Vector lives in the closure
>
> (Fixed a bug found by nosnap builds.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
> BUG=
>
> Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1
> Cr-Commit-Position: refs/heads/master@{#33548}
TBR=bmeurer@chromium.org,yangguo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1643533003
Cr-Commit-Position: refs/heads/master@{#33556}
This reverts commit 85ba94f28c.
All parallelism can be turned off using --predictable, or --noparallel-compaction.
This patch completely parallelizes
- semispace copy: from space -> to space (within newspace)
- newspace evacuation: newspace -> oldspace
- oldspace compaction: oldspace -> oldspace
Previously newspace has been handled sequentially (semispace copy, newspace
evacuation) before compacting oldspace in parallel. However, on a high level
there are no dependencies between those two actions, hence we parallelize them
altogether. We base the number of evacuation tasks on the overall set of
to-be-processed pages (newspace + oldspace compaction pages).
Some low-level details:
- The hard cap on number of tasks has been lifted
- We cache store buffer entries locally before merging them back into the global
StoreBuffer in a finalization phase.
- We cache AllocationSite operations locally before merging them back into the
global pretenuring storage in a finalization phase.
- AllocationSite might be compacted while they would be needed for newspace
evacuation. To mitigate any problems we defer checking allocation sites for
newspace till merging locally buffered data.
CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_asan_rel,v8_linux64_tsan_rel,v8_mac64_asan_rel
BUG=chromium:524425
LOG=N
R=hpayer@chromium.org, ulan@chromium.org
Review URL: https://codereview.chromium.org/1640563004
Cr-Commit-Position: refs/heads/master@{#33552}
(Fixed a bug found by nosnap builds.)
We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.
We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.
This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.
The heap change is trivial so I TBR Hannes for it...
TBR=hpayer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1642613002
Cr-Commit-Position: refs/heads/master@{#33548}
This ensures that the BytecodeGraphBuilder can generate correct graphs
even when deoptimization has not been enabled. This configuration is not
enabled in production, and we might eventually decide to deprecate it
for good. Until then, this is a quick fix.
R=jarin@chromium.org
TEST=cctest/test-pipeline
Review URL: https://codereview.chromium.org/1640683002
Cr-Commit-Position: refs/heads/master@{#33545}
Introduces the concept of transfer direction to register operands. This
enables the register translator to emit exactly the moves that a
bytecode having it's register operands translated needs.
BUG=v8:4280,v8:4675
LOG=N
Review URL: https://codereview.chromium.org/1633153002
Cr-Commit-Position: refs/heads/master@{#33544}
Reason for revert:
[Sheriff] Leads to crashes on all webrtc chromium testers, e.g.:
https://build.chromium.org/p/chromium.webrtc/builders/Mac%20Tester/builds/49664
Original issue's description:
> [heap] Parallel newspace evacuation, semispace copy, and compaction \o/
>
> All parallelism can be turned off using --predictable, or --noparallel-compaction.
>
> This patch completely parallelizes
> - semispace copy: from space -> to space (within newspace)
> - newspace evacuation: newspace -> oldspace
> - oldspace compaction: oldspace -> oldspace
>
> Previously newspace has been handled sequentially (semispace copy, newspace
> evacuation) before compacting oldspace in parallel. However, on a high level
> there are no dependencies between those two actions, hence we parallelize them
> altogether. We base the number of evacuation tasks on the overall set of
> to-be-processed pages (newspace + oldspace compaction pages).
>
> Some low-level details:
> - The hard cap on number of tasks has been lifted
> - We cache store buffer entries locally before merging them back into the global
> StoreBuffer in a finalization phase.
> - We cache AllocationSite operations locally before merging them back into the
> global pretenuring storage in a finalization phase.
> - AllocationSite might be compacted while they would be needed for newspace
> evacuation. To mitigate any problems we defer checking allocation sites for
> newspace till merging locally buffered data.
>
> CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_asan_rel,v8_linux64_tsan_rel,v8_mac64_asan_rel
> BUG=chromium:524425
> LOG=N
> R=hpayer@chromium.org, ulan@chromium.org
>
> Committed: https://crrev.com/8f0fd8c0370ae8c5aab56491b879d7e30c329062
> Cr-Commit-Position: refs/heads/master@{#33523}
TBR=hpayer@chromium.org,ulan@chromium.org,mlippautz@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:524425
Review URL: https://codereview.chromium.org/1643473002
Cr-Commit-Position: refs/heads/master@{#33539}
In a generator function, the parser rewrites a return statement into a "final"
yield. A final yield used to close the generator, which was incorrect because
the return may occur inside a try-finally clause and so the generator may not
yet terminate.
BUG=
Review URL: https://codereview.chromium.org/1634553002
Cr-Commit-Position: refs/heads/master@{#33537}
This patch stages the first part of RegExp subclassing--defining
Symbol.{match,replace,search,split}, but keeping their original
definitions which are restricted to a RegExp receiver and do not
call out to the core 'exec' method. This is being staged separately
because the two sets of extension points are separate features with
separate functionality. The amount of behavior which is held behind
the flag is very small, just exposing the symbols as properties of
Symbol--the behavior that the String methods call out to these Symbol
properties has already been shipping unflagged.
R=yangguo@chromium.org
BUG=v8:4305,v8:4343,v8:4344,v8:4345
LOG=Y
Review URL: https://codereview.chromium.org/1637703003
Cr-Commit-Position: refs/heads/master@{#33534}
Functions like DataView.prototype.getUint8 should have length 1,
and DataView.prototype.setUint8 should have length 2, as their
endianness arguments are optional. Additionally,
TypedArray.prototype.set.length should be 2. This follows the ES2015
specification, and a new test262 test tests for it. This patch
fixes the functions' lengths.
R=adamk
Review URL: https://codereview.chromium.org/1636953003
Cr-Commit-Position: refs/heads/master@{#33531}
ParseArrowFunctionLiteral was erroneously checking AllowsLazyCompilation
rather than AllowsLazyParsing when deciding whether to parse lazily.
This meant that lexically-scoped variables that had no other referents
wouldn't get closed over properly.
BUG=chromium:580934, v8:4255
LOG=y
Review URL: https://codereview.chromium.org/1630823006
Cr-Commit-Position: refs/heads/master@{#33530}
This makes it easier to see what behavior each test is verifying.
BUG=v8:3699
LOG=n
Review URL: https://codereview.chromium.org/1638853003
Cr-Commit-Position: refs/heads/master@{#33529}
They were already treated as a BindingPattern error; this patch simply
replaces that call with one marking them as both a binding and assignment
error, and adds parsing tests for both cases.
BUG=v8:4707
LOG=n
Review URL: https://codereview.chromium.org/1632303002
Cr-Commit-Position: refs/heads/master@{#33528}
It allows embedder to inject a stack sample on demand.
BUG=chromium:579191
LOG=N
Review URL: https://codereview.chromium.org/1631043002
Cr-Commit-Position: refs/heads/master@{#33527}
All parallelism can be turned off using --predictable, or --noparallel-compaction.
This patch completely parallelizes
- semispace copy: from space -> to space (within newspace)
- newspace evacuation: newspace -> oldspace
- oldspace compaction: oldspace -> oldspace
Previously newspace has been handled sequentially (semispace copy, newspace
evacuation) before compacting oldspace in parallel. However, on a high level
there are no dependencies between those two actions, hence we parallelize them
altogether. We base the number of evacuation tasks on the overall set of
to-be-processed pages (newspace + oldspace compaction pages).
Some low-level details:
- The hard cap on number of tasks has been lifted
- We cache store buffer entries locally before merging them back into the global
StoreBuffer in a finalization phase.
- We cache AllocationSite operations locally before merging them back into the
global pretenuring storage in a finalization phase.
- AllocationSite might be compacted while they would be needed for newspace
evacuation. To mitigate any problems we defer checking allocation sites for
newspace till merging locally buffered data.
CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_asan_rel,v8_linux64_tsan_rel,v8_mac64_asan_rel
BUG=chromium:524425
LOG=N
R=hpayer@chromium.org, ulan@chromium.org
Review URL: https://codereview.chromium.org/1577853007
Cr-Commit-Position: refs/heads/master@{#33523}
A statement could have several break positions. The entire statement
should be considered muted if break points across all these break
positions evaluate to false.
R=verwaest@chromium.org
BUG=chromium:429167
LOG=N
Review URL: https://codereview.chromium.org/1615903002
Cr-Commit-Position: refs/heads/master@{#33522}
This replace HeapType with a dedicated class that implements just what we need for field type tracking. In the next CL, I plan to remove FieldType::Iterator because FieldType can iterate over at most one map.
The ultimate plan is to get rid of templates in types.(h|cc) and remove type-inl.h.
TBR=rossberg@chromium.org
Review URL: https://codereview.chromium.org/1636013002
Cr-Commit-Position: refs/heads/master@{#33521}
Reason for revert:
FAilure on win32 bot, need to investigate webkit failures.
Original issue's description:
> Type Feedback Vector lives in the closure
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4
> Cr-Commit-Position: refs/heads/master@{#33518}
TBR=bmeurer@chromium.org,akos.palfi@imgtec.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1632993003
Cr-Commit-Position: refs/heads/master@{#33520}
We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.
We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.
This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.
The heap change is trivial so I TBR Hannes for it...
TBR=hpayer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1563213002
Cr-Commit-Position: refs/heads/master@{#33518}
This increases the size of register operands to be 16-bit.
Not all bytecodes have wide register variants, so when they are
needed a register translator will copy them into a small area
reserved at the top of the 8-bit register range and these registers
are supplied as arguments to the bytecode with 8-bit operands.
This is non-intrusive for typical bytecode where the number of
registers is less than 120. For bytecodes with wide register
operands (above the window) their index needs to be translated
to avoid the reserved translation window.
Enables splay.js to run in Octane and a handful of mjsunit tests.
BUG=v8:4280,v8:4675
LOG=NO
Review URL: https://codereview.chromium.org/1613163002
Cr-Commit-Position: refs/heads/master@{#33516}
- Remove semispace target capacity: It's unused and adds some unneeded
complexity
- Enforcing decl order for SemiSpace
- Move forward declarations in spaces.h to top
- Add all members to default constructor
BUG=chromium:581076
LOG=N
Review URL: https://codereview.chromium.org/1631713002
Cr-Commit-Position: refs/heads/master@{#33515}
This fixes the translation of 'throw' bytecodes to TurboFan graphs. The
correct runtime function is being used now, also the frame states are
attached to the correct nodes now.
R=mythria@chromium.org
TEST=cctest/test-run-jsexceptions/ThrowMessageIndirectly
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1636033002
Cr-Commit-Position: refs/heads/master@{#33513}
Rename IntepreterExceptionEntryHandler builtin to InterpreterEnterBytecodeDispatch
and use it as the return address when building interpreter frames during deopt.
This ensures that we restart execution of the outer frame at the correct
bytecode.
BUG=v8:4280,v8:4678
LOG=N
Review URL: https://codereview.chromium.org/1633633002
Cr-Commit-Position: refs/heads/master@{#33512}
Adds support for calling native function literals. Moves the logic for building
the native function's SharedFunctionInfo out of full-codegen into compiler.cc
to allow it to be shared between fullcodegen and Ignition.
BUG=v8:4686
LOG=N
Review URL: https://codereview.chromium.org/1635553002
Cr-Commit-Position: refs/heads/master@{#33510}
This CL implements PrepareForTailCall() mentioned in ES6 spec for full codegen, Crankshaft and Turbofan.
When debugger is active tail calls are disabled.
Tail calling can be enabled by --harmony-tailcalls flag.
BUG=v8:4698
LOG=Y
TBR=rossberg@chromium.org
Review URL: https://codereview.chromium.org/1609893003
Cr-Commit-Position: refs/heads/master@{#33509}
SpiderMonkey switched to 2, test262 tests for 2, and 2 is a reasonable, natural
value.
R=yangguo
Review URL: https://codereview.chromium.org/1616233002
Cr-Commit-Position: refs/heads/master@{#33504}
This patch makes Array.prototype.concat support subclassing Arrays
and constructing instances properly with Symbol.species. It is
guarded by the --harmony-species flag.
R=cbruni
LOG=Y
BUG=v8:4093
Review URL: https://codereview.chromium.org/1577043002
Cr-Commit-Position: refs/heads/master@{#33503}
This patch is a workaround to the performance regression caused by
implementing the ES2015 TypedArray prototype chain: Include a
per-TypedArray-subclass length getter so that the superclass getter does
not become polymorphic. The patch appears to fix a regression in the
Gameboy Octane benchmark.
BUG=chromium:579905
R=adamk
LOG=Y
Review URL: https://codereview.chromium.org/1624383003
Cr-Commit-Position: refs/heads/master@{#33501}
* Add caching to handling of dangling loads
* Add two unittests for load elimination on escaped objects
BUG=v8:4586
LOG=n
Review URL: https://codereview.chromium.org/1619103004
Cr-Commit-Position: refs/heads/master@{#33498}
This fixes corner cases where the start offsets of exception handler
regions within the handler table fall together. This assumption was
based on full-codegen code and no longer holds with the interpreter.
The tables however are still well nested and code has been added to
verify that in debug mode.
R=rmcilroy@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1633573002
Cr-Commit-Position: refs/heads/master@{#33495}
The current support for try-catch in the interpreter can handle most of
the cases appearing in our test suite. Also the flag in question did not
detect try-finally constructs. This removes the flag and instead extends
the test expectations.
R=rmcilroy@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1631593003
Cr-Commit-Position: refs/heads/master@{#33494}
If it's Smi::FromInt(0), the NULL check would trigger. Instead, use the
handle-zap value to mean "not set".
BUG=v8:3647,chromium:580651
R=vogelheim@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/1628173002
Cr-Commit-Position: refs/heads/master@{#33492}
- Completely rely on the concurrent sweeping state for SweepingCompleted()
- Rename the state accordingly.
CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_asan_rel,v8_linux64_tsan_rel,v8_mac64_asan_rel
R=hpayer@chromium.org
Review URL: https://codereview.chromium.org/1614953002
Cr-Commit-Position: refs/heads/master@{#33490}
Cleanup %ForInPrepare runtime entry, and unify common logic with
%ForInEnumerate (renamed from %GetPropertyNamesFast). Also introduce
a TupleType to properly type JSForInPrepare and its projections w/o
special hacks in the Typer. And fix %ForInNext and JSForInNext to be
consistent with fullcodegen again (after the proxy refactorings last
quarter).
R=jarin@chromium.org
BUG=v8:3650
LOG=n
Review URL: https://codereview.chromium.org/1631583002
Cr-Commit-Position: refs/heads/master@{#33487}
This CL implements loop assignment analysis, a pass over a loop's body
to record local variables that are assigned. This pre-pass is similar
to that done on the JavaScript AST for the same reason: avoid introducing
too many phis at loop headers when building a graph.
R=bradnelson@chromium.org,ahaas@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1617723003
Cr-Commit-Position: refs/heads/master@{#33486}
A recent ES2015 semantics web compatibility fix changed a WebKit
test from a syntax error to a known failure without a syntax
error. This confused the fuzzer infrastructure. This patch updates
the test expectations to the expected output, based on what the
new semantics provide.
R=machenbach,adamk
BUG=v8:4693
LOG=N
Review URL: https://codereview.chromium.org/1628013003
Cr-Commit-Position: refs/heads/master@{#33484}
moves, we move those to the node, and remove them from the
predecessors ("merge" them to the common node).
If only some of the moves are common, we don't do anything. This is
what this change addresses.
The bug linked below should be addressed by this change. The only
difference in codegen before/after the change that introduced the bug
was un-merged moves.
BUG=chromium:549262
LOG=N
Review URL: https://codereview.chromium.org/1527203002
Cr-Commit-Position: refs/heads/master@{#33481}
The web appears to depend on being able to redeclare functions-in-blocks
in sloppy mode (examples seen so far tend to redeclare identical functions,
most likely accidentally).
This patch opens a minimal hole: two same-named function declarations
in the same scope are allowed, only in sloppy mode.
BUG=v8:4693, chromium:579395
LOG=y
Review URL: https://codereview.chromium.org/1622723003
Cr-Commit-Position: refs/heads/master@{#33478}
Change the interpreter to always store the current context in the frame's
context slot instead of the function context. This makes it possible to
restore the correct context during deopt.
BUG=v8:4678,v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1604923002
Cr-Commit-Position: refs/heads/master@{#33477}
These tests have been disabled while support for try-finally was work in
progress. By now control flow is connected properly and the tests pass.
R=oth@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1626503002
Cr-Commit-Position: refs/heads/master@{#33474}
This adds an explicit ReThrow bytecode to be used in the modelling of
try-finally statements. An exception that is being re-thrown should not
trigger message object creation or location computation and hence cannot
use the existing Throw bytecode.
R=rmcilroy@chromium.org
TEST=cctest/test-interpreter/InterpreterTryFinally
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1621673002
Cr-Commit-Position: refs/heads/master@{#33472}
In case the receiver map has an enum cache, %ForInPrepare returns the
length of the actual enum cache, which might include properties that
are further down the transition tree tho.
R=jarin@chromium.org
BUG=v8:3650
LOG=n
Review URL: https://codereview.chromium.org/1619353002
Cr-Commit-Position: refs/heads/master@{#33469}
This models function local control flow through try-finally constructs
using a token dispatch mechanism. All paths through the finally block
are assigned a token, at the end of the finally block a switch construct
dispatches according to this token.
R=oth@chromium.org,rmcilroy@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1613443002
Cr-Commit-Position: refs/heads/master@{#33465}
Break and continue operations need to pop the context chain to the
correct context before jumping to the target.
BUG=v8:4280,v8:4678
LOG=N
Review URL: https://codereview.chromium.org/1618693002
Cr-Commit-Position: refs/heads/master@{#33464}
This fixes the broken return address when the exception handler within
interpreted bytecode is being entered via stack unwinding. The address
in question will never actually be taken, but our stack walker uses this
address to determine whether a frame is interpreted.
R=rmcilroy@chromium.org
TEST=cctest/test-interpreter/InterpreterTryCatch
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1615063002
Cr-Commit-Position: refs/heads/master@{#33463}
When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.
Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.
This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.
BUG=v8:4267
LOG=Y
Committed: https://crrev.com/1d3e837fcbbd9d9fd5e72dfe85dfd47c025f3c9f
Cr-Commit-Position: refs/heads/master@{#33438}
Review URL: https://codereview.chromium.org/1587073003
Cr-Commit-Position: refs/heads/master@{#33461}
Reason for revert:
let me quickly revert the revert, wut?
Goal: my CL should not be in the tree!
Original issue's description:
> Reland of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #1 id:1 of https://codereview.chromium.org/1619803003/ )
>
> Reason for revert:
> the deopt issues have been taken care of by benedikt
>
> Original issue's description:
> > Revert of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #10 id:180001 of https://codereview.chromium.org/1608523002/ )
> >
> > Reason for revert:
> > tanks for-in significantly
> >
> > Original issue's description:
> > > [runtime] Do not use the enum-cache for keys retrieval.
> > >
> > > Currently we fail to properly handle shadowed properties. If the
> > > receiver defines a non-enumerable property that reappears on the
> > > prototype as enumerable it incorrectly shows up in [[Enumerate]].
> > > By extending the KeyAccumulator to track non-enumerable properties
> > > we can now properly filter them out when seeing them further up in
> > > the prototype-chain.
> > >
> > > BUG=v8:705
> > > LOG=y
> > >
> > > Committed: https://crrev.com/ed24dfe80d1da0827b8571839ee52c03ad09c9c7
> > > Cr-Commit-Position: refs/heads/master@{#33405}
> >
> > TBR=jkummerow@chromium.org,bmeurer@chromium.org
> > # Not skipping CQ checks because original CL landed more than 1 days ago.
> > BUG=v8:705
> > LOG=n
> >
> > Committed: https://crrev.com/6e0573c6fff1c3041bab106d1197ab1b64aa9a6a
> > Cr-Commit-Position: refs/heads/master@{#33443}
>
> TBR=jkummerow@chromium.org,bmeurer@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:705
>
> Committed: https://crrev.com/5569e270eda517b5ea74e3a7676b3230cbe2f7a9
> Cr-Commit-Position: refs/heads/master@{#33458}
TBR=jkummerow@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:705
Review URL: https://codereview.chromium.org/1614313003
Cr-Commit-Position: refs/heads/master@{#33459}
Reason for revert:
the deopt issues have been taken care of by benedikt
Original issue's description:
> Revert of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #10 id:180001 of https://codereview.chromium.org/1608523002/ )
>
> Reason for revert:
> tanks for-in significantly
>
> Original issue's description:
> > [runtime] Do not use the enum-cache for keys retrieval.
> >
> > Currently we fail to properly handle shadowed properties. If the
> > receiver defines a non-enumerable property that reappears on the
> > prototype as enumerable it incorrectly shows up in [[Enumerate]].
> > By extending the KeyAccumulator to track non-enumerable properties
> > we can now properly filter them out when seeing them further up in
> > the prototype-chain.
> >
> > BUG=v8:705
> > LOG=y
> >
> > Committed: https://crrev.com/ed24dfe80d1da0827b8571839ee52c03ad09c9c7
> > Cr-Commit-Position: refs/heads/master@{#33405}
>
> TBR=jkummerow@chromium.org,bmeurer@chromium.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=v8:705
> LOG=n
>
> Committed: https://crrev.com/6e0573c6fff1c3041bab106d1197ab1b64aa9a6a
> Cr-Commit-Position: refs/heads/master@{#33443}
TBR=jkummerow@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:705
Review URL: https://codereview.chromium.org/1612413003
Cr-Commit-Position: refs/heads/master@{#33458}
The internal index used to implement for-in can never leave the
valid smi range, so there's no need to actually check for overflow
in Crankshaft. In fact the overflow only triggered a false alert
in the deopt fuzzer.
R=jarin@chromium.org
BUG=v8:3650
LOG=n
Review URL: https://codereview.chromium.org/1621623002
Cr-Commit-Position: refs/heads/master@{#33456}
Reason for revert:
The random nature of the tests caused the following buildbot to fail: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/4724/steps/Check/logs/stdio
Original issue's description:
> [profiler] Implement POC Sampling Heap Profiler
>
> This implements a proof-of-concept sampling based heap profiler inspired by
> tcmalloc's heap profiler [1] and Go's mprof/memprofile [2].
>
> The basic idea is the sample allocations using a randomized Poisson process. At
> any point in time we can cheaply request the set of live sample objects that
> should be a representative sample of heap. Samples include stack-traces from the
> allocation sites, making this an effective tool for memory leak debugging.
>
> Unlike AllocationTracking, this is intended to be cheap and usable online in
> production.
>
> The proof-of-concept is only sampling new-space allocations at this point.
> Support for sampling paged space and native allocations is anticipated in the
> future.
>
> [1] http://goog-perftools.sourceforge.net/doc/heap_profiler.html
> [2] http://blog.golang.org/profiling-go-programs
>
> Committed: https://crrev.com/e5a9947811db9c9e23557dbad27f8b8a349b3262
> Cr-Commit-Position: refs/heads/master@{#33448}
TBR=jochen@chromium.org,alph@chromium.org,hpayer@chromium.org,yangguo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1615173002
Cr-Commit-Position: refs/heads/master@{#33449}
This implements a proof-of-concept sampling based heap profiler inspired by
tcmalloc's heap profiler [1] and Go's mprof/memprofile [2].
The basic idea is the sample allocations using a randomized Poisson process. At
any point in time we can cheaply request the set of live sample objects that
should be a representative sample of heap. Samples include stack-traces from the
allocation sites, making this an effective tool for memory leak debugging.
Unlike AllocationTracking, this is intended to be cheap and usable online in
production.
The proof-of-concept is only sampling new-space allocations at this point.
Support for sampling paged space and native allocations is anticipated in the
future.
[1] http://goog-perftools.sourceforge.net/doc/heap_profiler.html
[2] http://blog.golang.org/profiling-go-programs
Review URL: https://codereview.chromium.org/1555553002
Cr-Commit-Position: refs/heads/master@{#33448}
Reason for revert:
[Sheriff] Breaks layout tests. Please fix upstream.
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/4077
Original issue's description:
> Array length reduction should throw in strict mode if it can't delete an element.
>
> When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.
>
> Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.
>
> This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.
>
> BUG=v8:4267
> LOG=Y
>
> Committed: https://crrev.com/1d3e837fcbbd9d9fd5e72dfe85dfd47c025f3c9f
> Cr-Commit-Position: refs/heads/master@{#33438}
TBR=verwaest@chromium.org,ishell@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4267
Review URL: https://codereview.chromium.org/1611313003
Cr-Commit-Position: refs/heads/master@{#33444}
Reason for revert:
tanks for-in significantly
Original issue's description:
> [runtime] Do not use the enum-cache for keys retrieval.
>
> Currently we fail to properly handle shadowed properties. If the
> receiver defines a non-enumerable property that reappears on the
> prototype as enumerable it incorrectly shows up in [[Enumerate]].
> By extending the KeyAccumulator to track non-enumerable properties
> we can now properly filter them out when seeing them further up in
> the prototype-chain.
>
> BUG=v8:705
> LOG=y
>
> Committed: https://crrev.com/ed24dfe80d1da0827b8571839ee52c03ad09c9c7
> Cr-Commit-Position: refs/heads/master@{#33405}
TBR=jkummerow@chromium.org,bmeurer@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:705
LOG=n
Review URL: https://codereview.chromium.org/1619803003
Cr-Commit-Position: refs/heads/master@{#33443}
Motivated by finding a bug in a larger module, this CL adds the ability
to dump out a byte-by-byte, nested view of the decoded AST. This
byte-by-byte output uses the opcode enum to make it readable, but is
suitable for pasting into a byte[] in C or JS and thus making a regression
test.
Also fix a bug; the case of running out of registers for indirect calls.
R=ahaas@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1616973004
Cr-Commit-Position: refs/heads/master@{#33442}
When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.
Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.
This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.
BUG=v8:4267
LOG=Y
Review URL: https://codereview.chromium.org/1587073003
Cr-Commit-Position: refs/heads/master@{#33438}
