When black allocation is turned on at deserialization time, then
slots in deserialized objects have to be visited by the incremental
marker. For spaces with reservations, this has always been done; for
large object space with its special handling, this patch adds it.
Additionally, we must ensure that no incremental steps that might
cause incremental marking to finish are performed while there is an
AlwaysAllocateScope around.
BUG=chromium:718859
Review-Url: https://codereview.chromium.org/2868103002
Cr-Commit-Position: refs/heads/master@{#45231}
Reason for revert:
buildbot failures
Original issue's description:
> [heap] Verify remembered set for objects in the old generation.
>
> Review-Url: https://codereview.chromium.org/2868053002
> Cr-Commit-Position: refs/heads/master@{#45225}
> Committed: 755a809ee5TBR=mlippautz@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/2870413002
Cr-Commit-Position: refs/heads/master@{#45227}
Added support for DINSM and DINSU bit insertion instructions. Also fixed
errors with bit extraction instructions, added disassembler tests and
adjusted the code to make it more compact.
BUG=
TEST=cctest/test-assembler-mips/Dins
cctest/test-disasm-mips/Type0
Review-Url: https://codereview.chromium.org/2871663002
Cr-Commit-Position: refs/heads/master@{#45226}
One of the serializer fuzzers passes in random data to the deserializer,
which can then be used to deserialize a JSRegExp instance with random flag
contents. This can cause issues since the JSRegExp::Flag enum statically
contains kDotAll - but it is only valid to set kDotAll iff
FLAG_harmony_regexp_dotall is set.
This CL verifies deserialized flags before constructing the JSRegExp
and bails out if they are invalid.
R=jbroman@chromium.org,yangguo@chromium.org
BUG=chromium:719280
Review-Url: https://codereview.chromium.org/2870743004
Cr-Commit-Position: refs/heads/master@{#45222}
This fixes cases where falling off the end of a non-void function was
accepted as a valid asm.js module. This led to translation failures in
the WASM code. Only void functions are allowed to fall off the end.
R=clemensh@chromium.org
TEST=mjsunit/asm/return-types
BUG=chromium:719286
Change-Id: I7b1c9ba5381b87a23cf0a2171bee5e5f5e8cd9de
Reviewed-on: https://chromium-review.googlesource.com/500312
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45221}
By C++ standard, behaviour is undedined when converting -Infinity to
integer. This patch assures correct behaviour in this case on all
platforms.
BUG=
Review-Url: https://codereview.chromium.org/2865113005
Cr-Commit-Position: refs/heads/master@{#45220}
Mechanical change to remove argument adaption from RegExp.p.split,
RegExp.p.replace when the actual arguments counts does not match
the formal parameter count (should be a tad faster this way).
BUG=v8:6369
Review-Url: https://codereview.chromium.org/2865313002
Cr-Commit-Position: refs/heads/master@{#45219}
Mechanical change to remove argument adaption from Array.p.indexOf and
Array.p.includes when the actual arguments counts does not match the formal
parameter count.
BUG=v8:6369
Review-Url: https://codereview.chromium.org/2873653002
Cr-Commit-Position: refs/heads/master@{#45218}
Isolate::ThrowException calls Debug::OnException, this method can potentially enter debugger context and on exception inspector can lazily compile injected-script-source so NO_SCRIPT_NO_EXCEPTIONS restriction looks too strict to me
R=jochen@chromium.org
BUG=v8:5830
Change-Id: Ic37aaa7bc6f2bd5922654f1a3c235d5eaacb8f85
Reviewed-on: https://chromium-review.googlesource.com/501351
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45217}
For small arrays, it's way faster to just move the elements instead of
doing the fairly complex and heavy-weight left-trimming. Crankshaft has
had this optimization for small arrays already; this CL more or less
ports this functionality to TurboFan, which yields a 4x speed-up when
using shift on small arrays (with up to 16 elements).
This should recover some of the regressions reported in the Node.js issues
https://github.com/nodejs/node/issues/12657
and discovered for the syncthrough module using
https://github.com/mcollina/syncthrough/blob/master/benchmarks/basic.js
as benchmark.
R=jarin@chromium.org
BUG=v8:6376
Review-Url: https://codereview.chromium.org/2874453002
Cr-Commit-Position: refs/heads/master@{#45216}
During i18n code reorg, a couple of changes for ICU 59 prep were
lost. Add them back.
See https://codereview.chromium.org/2738503008/ for the original CL.
BUG=v8:6062
TEST=v8 can be compiled with ICU 59 (hash: c28886684 ).
Change-Id: Ie19a40a9e54d0a8966dbe8e072f9afabf9e85e4f
Reviewed-on: https://chromium-review.googlesource.com/499609
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45213}
This CL introduces a new type, MapHandles, which is a STL vector of Handle<Map>.
It is now used everywhere where lists of Handle<Maps> are required, replacing
usages of V8's internal List type.
Also-By: franzih@chromium.org
BUG=v8:6333,v8:6325
LOG=N
Review-Url: https://codereview.chromium.org/2809923002
Cr-Commit-Position: refs/heads/master@{#45211}
- S32x4Shuffle by decomposing into s-register moves if no patterns match.
- S16x8Shuffle, S8x16Shuffle implemented with vtbl if no patterns match.
LOG=N
BUG=v8:6020
Review-Url: https://codereview.chromium.org/2856363003
Cr-Commit-Position: refs/heads/master@{#45210}
This reverts commit 26fdb617f5.
Reason for revert: v8:6378
Original change's description:
> [stubs] Properly convert the receiver for GetPropertyStub.
>
> Call ToObject on the GetPropertyStub input first, so that lookups on
> Strings and other primitives don't automatically hit the runtime, i.e.
> as the stub is also used to lookup the special @@split and @@replace
> symbols for various String builtins.
>
> BUG=v8:5269
> R=ishell@chromium.org
>
> Change-Id: I5dbbc84aa2051173bf10be71c782fbe448481034
> Reviewed-on: https://chromium-review.googlesource.com/488441
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44961}
TBR=ishell@chromium.org,bmeurer@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
BUG=v8:5269
Change-Id: I1e2e83b492d82656ead81ea35adbbcf5d324d2b8
Reviewed-on: https://chromium-review.googlesource.com/500135
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45206}
Bug: v8:6351
Change-Id: I6a5b44486bac87e2b3cb9aa93808b2c7964d6202
Reviewed-on: https://chromium-review.googlesource.com/499508
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45205}
Reason for revert:
Seems to break cfi:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20cfi/builds/9989
Original issue's description:
> [turbofan] Add alignment parameter to StackSlot operator
>
> If alignment parameter is set, the memory returned by the
> StackSlot operator will be aligned according to the parameter.
>
> The implementation goes like this. If alignment parameter is set
> we allocate a bit more memory than actually needed and so we
> can move the beginning of the StackSlot in order to have it aligned.
>
>
> BUG=
>
> Review-Url: https://codereview.chromium.org/2816743003
> Cr-Commit-Position: refs/heads/master@{#45197}
> Committed: d8bfdb7a99TBR=ahaas@chromium.org,clemensh@chromium.org,titzer@chromium.org,bmeurer@chromium.org,ivica.bogosavljevic@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/2867403002
Cr-Commit-Position: refs/heads/master@{#45203}
heap_find walks all the page of the heap and finds the references to a given
address.
NOTRY=true
Change-Id: I3271ab96d0224acf2361fe5bc4c8b0a608caf091
Reviewed-on: https://chromium-review.googlesource.com/500190
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45202}
This extension imitates user-interaction on a page by randomly clicking on
links matching a given regexp pattern.
Change-Id: I210bebf36ce6e3a3c785953010ce21528093d1af
NOTRY=true
Change-Id: I210bebf36ce6e3a3c785953010ce21528093d1af
Reviewed-on: https://chromium-review.googlesource.com/500247
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45201}
We can inline the allocation of the generator object as long as our
closure is constant.
BUG=v8:6352
Review-Url: https://codereview.chromium.org/2867603002
Cr-Commit-Position: refs/heads/master@{#45200}
Creation stack trace points to the place where callback was actually chained, scheduled points where parent promise was resolved.
For async tasks without creation stack (e.g. setTimeout) we continue to use scheduled as creation since usually they are the same.
BUG=v8:6189
R=dgozman@chromium.org
Review-Url: https://codereview.chromium.org/2868493002
Cr-Commit-Position: refs/heads/master@{#45198}
If alignment parameter is set, the memory returned by the
StackSlot operator will be aligned according to the parameter.
The implementation goes like this. If alignment parameter is set
we allocate a bit more memory than actually needed and so we
can move the beginning of the StackSlot in order to have it aligned.
BUG=
Review-Url: https://codereview.chromium.org/2816743003
Cr-Commit-Position: refs/heads/master@{#45197}
That's cleaner than having every target depending on v8 include icu
itself.
BUG=none
R=machenbach@chromium.org
Change-Id: Icaa9e8670718664041a6efe2622366c89b733f81
Reviewed-on: https://chromium-review.googlesource.com/500127
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45196}
Reason for revert:
Original CL reverted.
Crashing on Canary
BUG=chromium:718891
Original issue's description:
> PPC/s390: Reland: [TypeFeedbackVector] Store optimized code in the vector
>
> Port 662aa425ba
>
> Original Commit Message:
>
> Since the feedback vector is itself a native context structure, why
> not store optimized code for a function in there rather than in
> a map from native context to code? This allows us to get rid of
> the optimized code map in the SharedFunctionInfo, saving a pointer,
> and making lookup of any optimized code quicker.
>
> Original patch by Michael Stanton <mvstanton@chromium.org>
>
> R=rmcilroy@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
> BUG=v8:6246
> LOG=N
>
> Review-Url: https://codereview.chromium.org/2861863003
> Cr-Commit-Position: refs/heads/master@{#45111}
> Committed: d587812258TBR=joransiu@ca.ibm.com,jyan@ca.ibm.com,michael_dawson@ca.ibm.com,rmcilroy@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:6246
Review-Url: https://codereview.chromium.org/2870703003
Cr-Commit-Position: refs/heads/master@{#45195}
There's no point in using our own implemention of List for this.
Bug:v8:6333
Change-Id: Ic239c9348bb17d61e41130a18e1c9f16cab9d8ee
Reviewed-on: https://chromium-review.googlesource.com/489503
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45192}
This tests and fixes validation failures caused by assignments to
variables holding functions references (which are all considered
immutable). Such references can come from "stdlib" or "foreign".
R=clemensh@chromium.org
TEST=mjsunit/asm/global-imports
BUG=chromium:719382
Change-Id: Ic02be765e0773a6cc74a54e11a09d42ffb683cb8
Reviewed-on: https://chromium-review.googlesource.com/500188
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45189}
Before this fix, all existing suites would get wastefully initialized in each subprocess.
Bug: v8:6375
Change-Id: I68d961cde143754724735aecbac605852f89c7d9
Reviewed-on: https://chromium-review.googlesource.com/500187
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45188}
Before this, --print-bytecode flag was available in all Release builds
but did not actually print the bytecodes because OBJECT_PRINT is not set.
The output was pretty confusing:
[generating bytecode for function: ]
000002115442ABE9 <BytecodeArray[27]>[generating bytecode for function: main]
000002115442B069 <BytecodeArray[114]>[generating bytecode for function: Primes]
000002115442B729 <BytecodeArray[63]>[generating bytecode for function: Int32Array]
000002115442BB51 <BytecodeArray[175]>[generating bytecode for function: Primes.getPrimeCount]
000002115442BE81 <BytecodeArray[7]>[generating bytecode for function: Primes.isPrimeDivisible]
000002115442BFC9 <BytecodeArray[71]>[generating bytecode for function: Primes.addPrime]
000002115442C1C1 <BytecodeArray[31]>[generating bytecode for function: Primes.getPrime]
000002115442D7B1 <BytecodeArray[14]>
With this CL, --print-bytecode flag will always output bytecode, but
detailed info about constant pool and handler table are still guarded.
Bug:NO
Change-Id: Ie03be74520f45659303d1658da5b2acc02cf1b36
Reviewed-on: https://chromium-review.googlesource.com/497808
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Loo Rong Jie <loorongjie@gmail.com>
Cr-Commit-Position: refs/heads/master@{#45187}
Temporarily disable check for Etc/GMT and take it as well as
Etc/UTC until the root cause of crbug.com/719609 is found.
BUG=chromium:719609,v8:6252
TBR=adamk@chromium.org
Review-Url: https://codereview.chromium.org/2872873002
Cr-Commit-Position: refs/heads/master@{#45186}
Due to speculative optimizations, the compiler can run into situations
where it's asked perform impossible operations, like loading a tagged
element as a float64 instead. All of this is guaranteed to be in dead
code (unless there's a bug), but leads to confusion and violates
assumptions in the compiler (that make perfect sense for code that is
not dead). So teach LoadElimination not to mix up element accesses with
incompatible representations.
BUG=chromium:719479
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2866233002
Cr-Commit-Position: refs/heads/master@{#45185}
This is the next in the series of simplifying the logic to collect feedback
in compare bytecode handlers. An earlier cl (
https://chromium-review.googlesource.com/c/483399/) modified StrictEquals
bytecode handler. This cl inlines the type feedback collection for the
Equalbytecode handler.
Bug: v8:4280
Change-Id: I36210a2412bb84a3fdb982aabccf8cdefe87e30e
Reviewed-on: https://chromium-review.googlesource.com/498447
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45183}
