1) Alternate between processing v8 and wrappers
2) Once v8 is empty, try 3 rounds of finding the fixpoint between v8 and wrappers
3) After that, finalize once v8 marking deque is empty again
BUG=
Review-Url: https://codereview.chromium.org/2591383004
Cr-Commit-Position: refs/heads/master@{#41932}
Ignoring this linker warning will enable Chromium builds to start
treating all linker warnings as errors in Windows builds.
BUG=676417, 659007
Review-Url: https://codereview.chromium.org/2594013004
Cr-Commit-Position: refs/heads/master@{#41931}
These methods now return undefined upon finding a data property in the
prototype chain which shadows an accessor property, and when hitting
a Proxy, call the appropriate proxy traps.
R=cbruni@chromium.org, littledan@chromium.org
BUG=v8:5130
Review-Url: https://codereview.chromium.org/2592013003
Cr-Commit-Position: refs/heads/master@{#41929}
Reason for revert:
Causes crashes on Canary: crbug.com/676643
Original issue's description:
> Turn on icu_case_mapping by default
>
> Update string-capitalize expected result because now it
> passes all the tests in the file.
> Mark fast/js/string-capitalization as failing with no_i18n.
>
> Relanding after revert because the failure was taken care of
> by Adam's CL at https://codereview.chromium.org/2597543002 .
>
>
> BUG=v8:4477, v8:4476
> TEST=test262/{built-ins,intl402}/Strings/*, webkit/fast/js/*,
> mjsunit/string-case, intl/general/case*
>
> Cr-Original-Commit-Position: refs/heads/master@{#41834}
> Committed: 7c79e23c34
> Review-Url: https://codereview.chromium.org/2588963002
> Cr-Commit-Position: refs/heads/master@{#41883}
> Committed: a42c8c67deTBR=littledan@chromium.org,yangguo@chromium.org,jshin@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:4477, v8:4476, chromium:676643
Review-Url: https://codereview.chromium.org/2601553002
Cr-Commit-Position: refs/heads/master@{#41928}
Reason for revert:
This won't work because the finalization still checks whether both marking deques are empty, also calling into blink. So we never proceed there.
Original issue's description:
> [heap] Ensure progress when incrementally marking wrappers
>
> The problem here is estimating the marking step size for wrapper tracing. If the
> steps are too small, we cannot keep up with the mutator creating new wrappers.
> The result is an endless stream of incremental marking steps, alternating v8 and
> wrappers tracing, without ever finalizing in a GC.
>
> The mitigation here is to abort finding the fix point after 10 incremental
> iterations.
>
> A proper solution would track newly created wrappers on the blink side during
> wrapper tracing. Will give this more thought after the holidays.
>
> BUG=chromium:668164, chromium:468240
>
> Review-Url: https://codereview.chromium.org/2592403002
> Cr-Commit-Position: refs/heads/master@{#41923}
> Committed: a47417b893TBR=ulan@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:668164, chromium:468240
Review-Url: https://codereview.chromium.org/2602433002
Cr-Commit-Position: refs/heads/master@{#41924}
The problem here is estimating the marking step size for wrapper tracing. If the
steps are too small, we cannot keep up with the mutator creating new wrappers.
The result is an endless stream of incremental marking steps, alternating v8 and
wrappers tracing, without ever finalizing in a GC.
The mitigation here is to abort finding the fix point after 10 incremental
iterations.
A proper solution would track newly created wrappers on the blink side during
wrapper tracing. Will give this more thought after the holidays.
BUG=chromium:668164, chromium:468240
Review-Url: https://codereview.chromium.org/2592403002
Cr-Commit-Position: refs/heads/master@{#41923}
In certain corner-cases we would grow a FAST_ELEMENTS packed backing store of a
JS_ARGUMENTS_TYPE object without converting to holey elements kinds. As a side
effect you could then read out the_hole.
BUG=v8:5772
Review-Url: https://codereview.chromium.org/2597013004
Cr-Commit-Position: refs/heads/master@{#41921}
This CL changes the displayed names of "Callbacks" and "Runtime" to "Blink C++"
and "V8 C++" respectively.
NOTRY=true
Review-Url: https://codereview.chromium.org/2598993002
Cr-Commit-Position: refs/heads/master@{#41920}
The last remaining JS user of this in promise.js has recently been moved
to TF. The underlying FastObjectStub is still in use.
BUG=
Review-Url: https://codereview.chromium.org/2598973002
Cr-Commit-Position: refs/heads/master@{#41919}
Reason for revert:
still crashing with the known issues
Original issue's description:
> [turbofan] reenable escape analysis to further investigate crashes
>
> R=jarin@chromium.org
>
> BUG=chromium:669242
>
> Review-Url: https://codereview.chromium.org/2589163002
> Cr-Commit-Position: refs/heads/master@{#41857}
> Committed: fd4812323fTBR=jarin@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:669242
Review-Url: https://codereview.chromium.org/2601463002
Cr-Commit-Position: refs/heads/master@{#41918}
Reason for revert:
Speculative revert because of blocked roll: https://codereview.chromium.org/2596013002/
Original issue's description:
> [TypeFeedbackVector] Root literal arrays in function literals slots
>
> Literal arrays and feedback vectors for a function can be garbage
> collected if we don't have a rooted closure for the function, which
> happens often. It's expensive to come back from this (recreating
> boilerplates and gathering feedback again), and the cost is
> disproportionate if the function was inlined into optimized code.
>
> To guard against losing these arrays when we need them, we'll now
> create literal arrays when creating the feedback vector for the outer
> closure, and root them strongly in that vector.
>
> BUG=v8:5456
>
> Review-Url: https://codereview.chromium.org/2504153002
> Cr-Commit-Position: refs/heads/master@{#41893}
> Committed: 93df094081TBR=bmeurer@chromium.org,mlippautz@chromium.org,mvstanton@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2597163002
Cr-Commit-Position: refs/heads/master@{#41917}
Odd numbered floating-point register shouldn't be used as compare register
on mips32r6 architecture. In case cpu switches to FRE mode, writes to odd
numbered single-precision fp register will update upper part of even
double-precision register, which will corrupt the even register.
BUG=
Review-Url: https://codereview.chromium.org/2591063003
Cr-Commit-Position: refs/heads/master@{#41916}
Reason for revert:
speculative revert: https://codereview.chromium.org/2596013002/
Original issue's description:
> [regexp] Remove IsRegExp intrinsic
>
> The two remaining uses of this intrinsic in debug.js and mirrors.js now
> simply rely on the runtime function.
>
> BUG=v8:5339
>
> Review-Url: https://codereview.chromium.org/2591923003
> Cr-Commit-Position: refs/heads/master@{#41892}
> Committed: c9cb94a06fTBR=bmeurer@chromium.org,jgruber@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5339
Review-Url: https://codereview.chromium.org/2592383002
Cr-Commit-Position: refs/heads/master@{#41915}
* Ensure that a source position is already specified in generated code before
prologue is assembled.
* Ensure source position is set for instructions before their gaps are assembled
(this fixes missing source position information at the beginning of deferred
code).
* Don't output source position information for gap moves that are
redundant. This led to extraneous, confusing source positions for constants
that did not end up producing any code.
* Output source position information that is usable in turbolizer when --trace-turbo
is specified.
LOG=N
Review-Url: https://codereview.chromium.org/2599433002
Cr-Commit-Position: refs/heads/master@{#41914}
Also support inlining the builtins String.prototype.charCodeAt and
String.prototype.charAt if the index type is not statically known
to be in the Unsigned32 range, but in anything in Integral32 plus
minus zero and NaN.
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2597913002
Cr-Commit-Position: refs/heads/master@{#41913}
Introduce a dedicated StringCharCodeAt builtin, that performs the core
logic of String.prototype.charCodeAt and lower the StringCharCodeAt
simplified operator to a call to this builtin rather than inlining the
full functionality into each and every TurboFan graph using it. This can
significantly reduce compile time in some cases (i.e. can easily shave
off over 50% of compile time overhead for small functions that call
String.prototype.charCodeAt).
Currently it returns the char code as TaggedSigned value, but
middle-term we should make it possible to return untagged values
from builtins.
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2600443002
Cr-Commit-Position: refs/heads/master@{#41912}
Previously String element access and String.prototype.charAt were
lowered to a subgraph StringFromCharCode(StringCharCodeAt(s, k)),
however that can be fairly expensive both runtime and compile time
wise. The dedicated StringCharAt operator is implemented via a call
to a builtin that does exactly this.
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2599683002
Cr-Commit-Position: refs/heads/master@{#41909}
This CL includes several small bug fixes for trap handlers. Among the changes:
* Use the correct representation for ProtectedLoads, enabling protected loads of
floating point types.
* Including the protected instruction list in what gets serialized for Code
objects. This is needed to allow deserialization for Wasm modules to work.
* Get the context needed to through and exception from the Isolate rather than
getting it as a parameter to the Protected instructions. Passing it in as an
argument is problematic when code is compiled ahead of time, as the context
may not be known yet. The new approach is similar to how it works for TrapIf
and TrapUnless.
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
Review-Url: https://codereview.chromium.org/2591903002
Cr-Commit-Position: refs/heads/master@{#41907}
This patch also refactors most of PromiseThen into InternalPromiseThen to
be reused with PromiseCatch and also changes InternalResolvePromise to
return and not branch.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2596553002
Cr-Commit-Position: refs/heads/master@{#41902}
Change bytecode-expectations-printer.cc in the cctest application so
that intrinsic function names are printed rather than their native
context index.
This minimizes the amount of unnecessary changes to the bytecode
expectations that need to happen whenever the context fields are
changed.
BUG=v8:5769
R=neis@chromium.org, rmcilroy@chromium.org, adamk@chromium.org
Review-Url: https://codereview.chromium.org/2593823002
Cr-Commit-Position: refs/heads/master@{#41900}
Port 93df094081
Original Commit Message:
Literal arrays and feedback vectors for a function can be garbage
collected if we don't have a rooted closure for the function, which
happens often. It's expensive to come back from this (recreating
boilerplates and gathering feedback again), and the cost is
disproportionate if the function was inlined into optimized code.
To guard against losing these arrays when we need them, we'll now
create literal arrays when creating the feedback vector for the outer
closure, and root them strongly in that vector.
R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:5456
LOG=N
Review-Url: https://codereview.chromium.org/2592043003
Cr-Commit-Position: refs/heads/master@{#41898}
Reason for revert:
Breaks tree:
http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/9970
Original issue's description:
> abstract_code: return compiled code for compiled shared funcs
>
> SharedFunctionInfo's abstract_code was returning the bytecode array
> whenever SharedFunctionInfo had a bytecode array, even if the function
> was compiled (e.g. tiered up to FCG). This meant that abstract_code
> could return code that is not actually the code that will run, which was
> causing problems in profiling as the sampled PC did not match the known
> code offset.
>
> This patch changes both SharedFunctionInfo and JSFunction to return the
> bytecode if-and-only-if they are not compiled and have a bytecode array
> to return, or they already point to the interpreter trampoline.
>
> BUG=v8:5758
>
> Review-Url: https://codereview.chromium.org/2592703002
> Cr-Commit-Position: refs/heads/master@{#41894}
> Committed: 679b31c214TBR=bmeurer@chromium.org,mstarzinger@chromium.org,mvstanton@chromium.org,mythria@chromium.org,rmcilroy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5758
Review-Url: https://codereview.chromium.org/2591223002
Cr-Commit-Position: refs/heads/master@{#41896}
On ARM Neon at least, denormals flush to zero, which may not match
regular FP behavior.
LOG=N
BUG=v8:4124
Review-Url: https://codereview.chromium.org/2598583002
Cr-Commit-Position: refs/heads/master@{#41895}
SharedFunctionInfo's abstract_code was returning the bytecode array
whenever SharedFunctionInfo had a bytecode array, even if the function
was compiled (e.g. tiered up to FCG). This meant that abstract_code
could return code that is not actually the code that will run, which was
causing problems in profiling as the sampled PC did not match the known
code offset.
This patch changes both SharedFunctionInfo and JSFunction to return the
bytecode if-and-only-if they are not compiled and have a bytecode array
to return, or they already point to the interpreter trampoline.
BUG=v8:5758
Review-Url: https://codereview.chromium.org/2592703002
Cr-Commit-Position: refs/heads/master@{#41894}
Literal arrays and feedback vectors for a function can be garbage
collected if we don't have a rooted closure for the function, which
happens often. It's expensive to come back from this (recreating
boilerplates and gathering feedback again), and the cost is
disproportionate if the function was inlined into optimized code.
To guard against losing these arrays when we need them, we'll now
create literal arrays when creating the feedback vector for the outer
closure, and root them strongly in that vector.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2504153002
Cr-Commit-Position: refs/heads/master@{#41893}
The two remaining uses of this intrinsic in debug.js and mirrors.js now
simply rely on the runtime function.
BUG=v8:5339
Review-Url: https://codereview.chromium.org/2591923003
Cr-Commit-Position: refs/heads/master@{#41892}
This is more renaming work to comply with the naming in the public
design repository. E.g. types are called "value types" and we no longer
refer to ASTs.
R=clemensh@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2594993002
Cr-Commit-Position: refs/heads/master@{#41891}
No need to untag/tag flags, and we can also omit the write barrier.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2591193002
Cr-Commit-Position: refs/heads/master@{#41890}
Also, provide a variadic template Return function for easier use, and
refactor the underlying Return function to not use the Buffer, since
that might still be needed later (for example if trap code is generated
during CallIndirect, and the arguments to the call are stored in the
buffer).
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2591903003
Cr-Commit-Position: refs/heads/master@{#41888}
The methods Intl.NumberFormat.prototype.v8Parse and
Intl.DateTimeFormat.prototype.v8Parse were removed several months
ago due to low usage and lack of standardization potential. This
patch removes some runtime functions used to implement them, which
were accidentally left in when they were taken out.
BUG=v8:3785
Review-Url: https://codereview.chromium.org/2591103003
Cr-Commit-Position: refs/heads/master@{#41887}
