Use the correct sNaN value on mips32r6 also.
TEST=test-api/QuietSignalingNaNs,test-api/Threading1
BUG=
Review URL: https://codereview.chromium.org/1311473007
Cr-Commit-Position: refs/heads/master@{#30510}
Now that it is no longer needed, this also removes the invalid inclusion
of "object-inl.h" within the "unique.h" header file.
Note that this change still leaves 2 violations of that rule in the
code, checked with the "tools/check-inline-includes.sh" tool.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1321223002
Cr-Commit-Position: refs/heads/master@{#30503}
Reason for revert:
Precautionary revert. The change is incomplete.
Original issue's description:
> heap: make array buffer maps disjoint
>
> Remove intersection from the `std::map`s representing current live
> ArrayBuffers. While being simpler to understand, it poses significant
> performance issue for the active ArrayBuffer users (like node.js).
>
> Store buffers separately, and process them together during mark-sweep phase.
>
> The results of benchmarks are:
>
> $ ./node-slow bench && ./node-fast bench
> 4997.4 ns/op
> 4685.7 ns/op
>
> NOTE: `fast` - was a patched node.js, `slow` - unpatched node.js with vanilla v8.
>
> BUG=
>
> Committed: https://crrev.com/9e3676da9ab1aaf7de3e8582cb3fdefcc3dbaf33
> Cr-Commit-Position: refs/heads/master@{#30495}
TBR=hpayer@chromium.org,fedor@indutny.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1302233007
Cr-Commit-Position: refs/heads/master@{#30502}
Reason for revert:
[Sheriff] Breaks test with greedy allocator:
http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug%20-%20greedy%20allocator/builds/1318
Original issue's description:
> [turbofan] greedy: heuristic for memory operands
>
> When we have a memory operand (HasSpillOperand() == true), and it
> doesn't need a register immediately, split in an optimal position, which
> is outside the outermost possible loop - just like Linear does.
>
> This results in some modest improvements in perf, when compared
> to baseline greedy. In particular Jetstream zlib x64: 4.66%, Life
> (Emscripten x64) 11%; largest regression is in AreWeFastYet x64: 8%
> and Corrections (Emsccripten x32) 10%
>
> BUG=
>
> Committed: https://crrev.com/8937bfc1d165ff6d72dede1b0ce6f7c1ab9fb260
> Cr-Commit-Position: refs/heads/master@{#30498}
TBR=jarin@chromium.org,bmeurer@chromium.org,mtrofin@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1311813005
Cr-Commit-Position: refs/heads/master@{#30501}
This CL us a pure refactoring that makes an empty compilation unit
including just "isolate.h" or "contexts.h" but not "objects-inl.h"
compile without warnings or errors. This is needed to further reduce
the header dependency tangle.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1322883002
Cr-Commit-Position: refs/heads/master@{#30500}
The code was previously reading unsigned integers by performing an invalid cast
of Operator1<intNN_t> objects to Operator1<uintNN_t> and reading the integer
directly. To fix the invalid cast, we cast to the correct type and static_cast
the integer to uintNN_t, which is a no-op on every reasonable target.
Cleanup for cfi_vptr=1; see https://www.chromium.org/developers/testing/control-flow-integrity
BUG=chromium:457523
R=bmeurer@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/1310633004
Cr-Commit-Position: refs/heads/master@{#30499}
When we have a memory operand (HasSpillOperand() == true), and it
doesn't need a register immediately, split in an optimal position, which
is outside the outermost possible loop - just like Linear does.
This results in some modest improvements in perf, when compared
to baseline greedy. In particular Jetstream zlib x64: 4.66%, Life
(Emscripten x64) 11%; largest regression is in AreWeFastYet x64: 8%
and Corrections (Emsccripten x32) 10%
BUG=
Review URL: https://codereview.chromium.org/1306823005
Cr-Commit-Position: refs/heads/master@{#30498}
This CL introduces HPrologue instruction which does the context allocation work and supports deoptimization.
Review URL: https://codereview.chromium.org/1317383002
Cr-Commit-Position: refs/heads/master@{#30496}
Remove intersection from the `std::map`s representing current live
ArrayBuffers. While being simpler to understand, it poses significant
performance issue for the active ArrayBuffer users (like node.js).
Store buffers separately, and process them together during mark-sweep phase.
The results of benchmarks are:
$ ./node-slow bench && ./node-fast bench
4997.4 ns/op
4685.7 ns/op
NOTE: `fast` - was a patched node.js, `slow` - unpatched node.js with vanilla v8.
BUG=
Review URL: https://codereview.chromium.org/1316873004
Cr-Commit-Position: refs/heads/master@{#30495}
We completely un-wired the greedy allocator to focus on the
stackchecks in loops (splintering) work. This change re-wires greedy,
still behind its flag. For now, enabling the greedy allocator disables
the stackchecks in loops feature (and range splintering), so that we are
at the baseline we left it at.
The main contribution in this change is adapting the codebase after
the live range model refactoring, whereby RegisterAllocationData's
live_ranges() contains just top-level ranges, and children are accessed
via their parents.
BUG=
Review URL: https://codereview.chromium.org/1320363002
Cr-Commit-Position: refs/heads/master@{#30492}
We were previously reading a language mode from all comparison nodes
in JSGenericLowering::ReplaceWithCompareIC. This read was invalid for
{,Strict}{,Not}Equal nodes, as these nodes do not have a language mode, as they
derive from Operator rather than from Operator1<LanguageMode>. Because these
nodes are not language mode dependent, we arbitrarily pass Strength::WEAK
to CodeFactory::CompareIC.
Cleanup for cfi_vptr=1; see https://www.chromium.org/developers/testing/control-flow-integrity
BUG=chromium:457523
R=bmeurer@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/1319463003
Cr-Commit-Position: refs/heads/master@{#30491}
Reason for revert:
Broke a test
Original issue's description:
> Fix CPU profiler deadlock on Windows + AMD CPU.
>
> Implement a lock free version of RolloverProtectedTickClock::Now
> to eliminate a deadlock.
>
> BUG=chromium:521420
> LOG=Y
>
> Committed: https://crrev.com/d6db8e5902af1f067f0f149844f4e92824ee93f3
> Cr-Commit-Position: refs/heads/master@{#30489}
TBR=yurys@chromium.org,caseq@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:521420
Review URL: https://codereview.chromium.org/1303423006
Cr-Commit-Position: refs/heads/master@{#30490}
Implement a lock free version of RolloverProtectedTickClock::Now
to eliminate a deadlock.
BUG=chromium:521420
LOG=Y
Review URL: https://codereview.chromium.org/1304873011
Cr-Commit-Position: refs/heads/master@{#30489}
The interrupts are already postponed in message handlers [1]. This CL aligns debug event listener (the mechanism that is actually used in Chrome DevTools) implementation with that. Handling interrupts on events like v8::AfterCompile leads to crashes like the one in the lined bug. This happens because in the interrupt handler we may change debugger state.
[1] https://codereview.chromium.org/309533009/diff/40001/src/debug.cc
BUG=chromium:520702
LOG=Y
Review URL: https://codereview.chromium.org/1321263002
Cr-Commit-Position: refs/heads/master@{#30488}
This is a change for ES2015. Date objects have mutable state, so having
a mutable prototype is bad for SES requirements, and it is an
inconsistency from the typical ES2015 class style of objects
BUG=v8:4004
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1317403002
Cr-Commit-Position: refs/heads/master@{#30486}
Port fbad63669e
Original commit message:
The call protocol requires that the register dedicated to the number of
actual arguments (i.e. rax on x64) always contains the actual arguments.
That means after adapting arguments it should match the number of
expected arguments. But currently we pass some semi-random value
(usually some stack address) after adapting arguments.
It looks like this is currently not observable anywhere, because our
builtins and functions either don't look at the number of arguments and
just make hard coded (unchecked) assumptions, or are marked as "don't
adapt arguments", which bypasses the broken code in the trampoline for
arguments adaption. Nevertheless this should be fixed.
BUG=
Review URL: https://codereview.chromium.org/1322953002
Cr-Commit-Position: refs/heads/master@{#30485}
Unbounded is defined in terms of None any Any,
which don't require an explicit zone.
Switching Unbounded to be the same.
BUG= None
TEST= trybots
R= titzer@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/1322003002
Cr-Commit-Position: refs/heads/master@{#30482}
Port fbad63669e
Original commit message:
The call protocol requires that the register dedicated to the number of
actual arguments (i.e. rax on x64) always contains the actual arguments.
That means after adapting arguments it should match the number of
expected arguments. But currently we pass some semi-random value
(usually some stack address) after adapting arguments.
It looks like this is currently not observable anywhere, because our
builtins and functions either don't look at the number of arguments and
just make hard coded (unchecked) assumptions, or are marked as "don't
adapt arguments", which bypasses the broken code in the trampoline for
arguments adaption. Nevertheless this should be fixed.
R=bmeurer@chromium.org, jyan@ca.ibm.com, dstence@us.ibm.com, joransiu@ca.ibm.com
BUG=
Review URL: https://codereview.chromium.org/1306953005
Cr-Commit-Position: refs/heads/master@{#30480}
This CL us a pure refactoring that makes an empty compilation unit
including just "frames.h" but not "handles-inl.h" compile without
warnings or errors. This is needed to further reduce the header
dependency tangle.
R=ishell@chromium.org
Review URL: https://codereview.chromium.org/1319423003
Cr-Commit-Position: refs/heads/master@{#30476}
This way we don't need to expose JSReceiver::OrdinaryToPrimitive
as runtime function, and we don't need the separate JS trampoline.
This also adds tests for ToPrimitive on date objects, which are
special.
R=mstarzinger@chromium.org
BUG=v8:4307
LOG=n
Review URL: https://codereview.chromium.org/1324713002
Cr-Commit-Position: refs/heads/master@{#30473}
- Move fast paths from builtins.cc ArraySlice to ElementsAccessor
- Handle more argument types in the fast path
BUG=
Review URL: https://codereview.chromium.org/1321773002
Cr-Commit-Position: refs/heads/master@{#30471}
The default equality comparison operators and hashing functions for
Handles are ambiguous. The intended semantics might have either been
based on Handle locations or on object identity. This is why such
operators do not exist on Handle. The same argument applies to the
MaybeHandle class as well. Comments in that regard were also added.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1319383002
Cr-Commit-Position: refs/heads/master@{#30468}
The call protocol requires that the register dedicated to the number of
actual arguments (i.e. rax on x64) always contains the actual arguments.
That means after adapting arguments it should match the number of
expected arguments. But currently we pass some semi-random value
(usually some stack address) after adapting arguments.
It looks like this is currently not observable anywhere, because our
builtins and functions either don't look at the number of arguments and
just make hard coded (unchecked) assumptions, or are marked as "don't
adapt arguments", which bypasses the broken code in the trampoline for
arguments adaption. Nevertheless this should be fixed.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1306423003
Cr-Commit-Position: refs/heads/master@{#30467}
Found this while working on the unit tests for split/splinter/merge. The
dependency is unnecessary and hinders testability.
BUG=
Review URL: https://codereview.chromium.org/1325453005
Cr-Commit-Position: refs/heads/master@{#30465}
The constructor taking an artificial raw address was only used as a
workaround in TurboFan. It should only be accessible by constructor
functions internal to Unique<T>.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1326493002
Cr-Commit-Position: refs/heads/master@{#30464}
Reason for revert:
Breaks http://build.chromium.org/p/client.v8/builders/V8%20Arm%20-%20debug%20-%202/builds/2372
Original issue's description:
> [heap] GC flag cleanup/restructuring.
>
> * GC's flags are now proper flags and not int.
> * Callback flags are not threaded through but only set once like gc flags
> * Callers of methods that trigger GCs need to pass a reason when not using
> the default parameters.
>
> Furthermore, each GC invocation can be passed the GC and GCCallback flags. We
> usually override the currently set flags upon finishing a GC cylce, but are able
> to restore the previously set if desired. This is useful for explicitely
> triggered scavenges or external requests that interrupt the current behaviour.
>
> BUG=
>
> Committed: https://crrev.com/f4f3b431b9ce0778d926acf03c0d36dae5c0cba4
> Cr-Commit-Position: refs/heads/master@{#30457}
TBR=hpayer@chromium.org,yangguo@chromium.org,mlippautz@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1303393004
Cr-Commit-Position: refs/heads/master@{#30463}
