Adds basic support for iterating interpreter stack frames for GC. Currently
InterpreterStackFrames are treated just like JavaScriptStackFrames since the
JavaScriptFrame::IterateExpressions() will correctly iterate over all the
local / temp interpeter Registers, and will iterate over the
interpreter_entry_trampoline pc address. There is no need to explicitly
iterate over the BytecodeArray object since that is held in a machine
register in the bytecode handler which is marked as kMachTaggedAny by
TurboFan, and so will get iterated appropriately when iterating the
bytecode handler stub's stack frame.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1407513003
Cr-Commit-Position: refs/heads/master@{#31342}
Reason for revert:
Waterfall redness.
Original issue's description:
> [turbofan] Initial support for monomorphic/polymorphic property loads.
>
> Native context specialization now lowers monomorphic and
> polymorphic accesses to data and constant data properties on
> object and/or prototype chain. We don't deal with accessors
> yet, and we also completely ignore proxies (which is compatible
> with what Crankshaft does).
>
> The code is more or less the straightforward implementation. We
> will need to refactor that and extract common patterns once the
> remaining bits for full load/store support is in.
>
> CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
> R=jarin@chromium.org
> BUG=v8:4470
> LOG=n
>
> Committed: https://crrev.com/3a0bf860b7177f7abef01ff308a53603389d958e
> Cr-Commit-Position: refs/heads/master@{#31340}
TBR=bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4470
Review URL: https://codereview.chromium.org/1408123002
Cr-Commit-Position: refs/heads/master@{#31341}
Native context specialization now lowers monomorphic and
polymorphic accesses to data and constant data properties on
object and/or prototype chain. We don't deal with accessors
yet, and we also completely ignore proxies (which is compatible
with what Crankshaft does).
The code is more or less the straightforward implementation. We
will need to refactor that and extract common patterns once the
remaining bits for full load/store support is in.
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
R=jarin@chromium.org
BUG=v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1396333010
Cr-Commit-Position: refs/heads/master@{#31340}
This fixes the lifetime of nodes created by JSGlobalSpecialization that
contain a simplified operator. In the case where this reducer runs as
part of the inliner, the SimplifiedOperatorBuilder was instantiated with
the wrong zone. This led to use-after-free of simplified operators.
To avoid such situations in the future, we decided to move this operator
builder into the JSGraph and make the situation uniform with all other
operator builders.
R=bmeurer@chromium.org
BUG=chromium:543528
LOG=n
Review URL: https://codereview.chromium.org/1409993002
Cr-Commit-Position: refs/heads/master@{#31334}
To be useful for narrowing down bugs, --hydrogen-filter shouldn't prevent any
inlining that the function(s) being allowed to get optimized want(s) to do.
Free bonus content in this CL: support FLAG_stop_at in lithium-codegen-arm64,
copied from full-codegen-arm64.
Review URL: https://codereview.chromium.org/1407043004
Cr-Commit-Position: refs/heads/master@{#31333}
Reason for revert:
Failing: https://chromegw.corp.google.com/i/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/2115
Original issue's description:
> Reland of "[heap] Divide available memory upon compaction tasks"
>
> This reverts commit ec1046f9f8.
>
> Original message:
>
> [heap] Divide available memory upon compaction tasks
> - Fairly (round-robin) divide available memory upon compaction tasks.
> - Ensure an upper limit (of memory) since dividing is O(n) for n free-space
> nodes.
> - Refill from free lists managed by sweeper once a compaction space becomes
> empty.
>
> Assumption for dividing memory: Memory in the free lists is sparse upon starting
> compaction (which means that only few nodes are available), except for memory
> reducer GCs, which happen in idle time though (so it's less of a problem).
>
> BUG=chromium:524425
> LOG=N
>
> Committed: https://crrev.com/a805be73f6f97645450124f75c0f7417ec7b3e70
> Cr-Commit-Position: refs/heads/master@{#31329}
TBR=hpayer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:524425
Review URL: https://codereview.chromium.org/1412643002
Cr-Commit-Position: refs/heads/master@{#31332}
This reverts commit ec1046f9f8.
Original message:
[heap] Divide available memory upon compaction tasks
- Fairly (round-robin) divide available memory upon compaction tasks.
- Ensure an upper limit (of memory) since dividing is O(n) for n free-space
nodes.
- Refill from free lists managed by sweeper once a compaction space becomes
empty.
Assumption for dividing memory: Memory in the free lists is sparse upon starting
compaction (which means that only few nodes are available), except for memory
reducer GCs, which happen in idle time though (so it's less of a problem).
BUG=chromium:524425
LOG=N
Review URL: https://codereview.chromium.org/1399403002
Cr-Commit-Position: refs/heads/master@{#31329}
Adds Scope::MaxNestedContextChainLength() which calculates the maximum length
of the context chain for the given scope. This is used by the interpreter to
preallocate the approprate number of context registers when compiling the
function.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1404793004
Cr-Commit-Position: refs/heads/master@{#31309}
- The bug is that we did not handle end_ properly in SearchForNodeInList.
- We now consistently account for sizes on page level in FreeList, except when
filtering evacuation candidates (those are accounted for in FreeListCategory)
BUG=chromium:524425
LOG=N
Review URL: https://codereview.chromium.org/1389293005
Cr-Commit-Position: refs/heads/master@{#31307}
In the ES2015 spec, RegExp uses ToLength, not ToInteger, on lastIndex
to coerce it to an integer. This patch switches to ToLength when
the --harmony-tolength flag is on, and adds some tests to verify the
new behavior.
BUG=v8:4244
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1394023005
Cr-Commit-Position: refs/heads/master@{#31306}
The runtime flag in question makes no sense, because the feature cannot
be disabled without keeping the snapshot in sync. We should avoid having
the flag in our "mjsunit" test suite, so that CluserFuzz doesn't pick it
up. The test in question is already skipped, the change will not affect
test results on our waterfall.
R=mvstanton@chromium.org
TEST=mjsunit/call-counts
BUG=v8:4458
LOG=n
Review URL: https://codereview.chromium.org/1409533003
Cr-Commit-Position: refs/heads/master@{#31302}
Reason for revert:
Weird endless loop in TopLevelLiveRange::Merge() due to always splitting first and not making progress. See comments, unfortunately no useable repro.
Original issue's description:
> [turbofan] Splinter into one range.
>
> Before this CL, we created one live range per successive set of
> deferred blocks. For scenarios with many such blocks, this creates
> an upfront pressure for the register allocator to deal with many ranges.
> Linear sorts ranges, which is a super-linear operation.
>
> The change places all deferred intervals into one range, meaning that,
> at most, there will be twice as many live ranges as the original set. In
> pathological cases (benchmarks/Compile/slow_nbody1.js), this change
> halves the compilation time. We see some improvements elsewhere,
> notably SQLite at ~4-5%.
>
> We may be able to avoid the subsequent merge. Its cost is the
> additional ranges it may need to create. The sole reason for the merge
> phase is to provide an unchanged view of the world to the subsequent
> phases. With the at-most-one splinter model, we may be able to teach
> the other phases about splintering - should we find perf hindrances
> due to merging.
>
> Committed: https://crrev.com/efdcd20267870276c5824f1ccf4e171ac378f7ae
> Cr-Commit-Position: refs/heads/master@{#31224}
TBR=jarin@chromium.org,mtrofin@google.com,mtrofin@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1403163003
Cr-Commit-Position: refs/heads/master@{#31300}
Even though the change is ES6 spec compliant, we decided to revert
to be consistent with other browsers and work on fixing the spec.
Original issue's description:
> Make dates default to the local timezone if none specified
>
> In ES5, dates were supposed to default to UTC if no timezone was specified. However, this changed in ES6, which specified that dates should be in the local timezone if no timezone was specified. This CL updates our behavior to match that part of the ES6 spec.
> BUG=chromium:391730, v8:4242
> LOG=Y
> Committed: https://crrev.com/f06754a8e1d305a43560705f6c167d85d40e602d
> Cr-Commit-Position: refs/heads/master@{#29854}
BUG=chromium:543320,chromium:539813
LOG=NO
Review URL: https://codereview.chromium.org/1403153003
Cr-Commit-Position: refs/heads/master@{#31295}
This is in preparation to enabling --turbo-inlining by default, fixing
various issues when general purpose inlining is running against our
entire test suite.
R=bmeurer@chromium.org
BUG=v8:4493
LOG=n
Review URL: https://codereview.chromium.org/1407533004
Cr-Commit-Position: refs/heads/master@{#31294}
This change add a new bytecode for operator new and implements it using
the Construct() builtin.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1402943002
Cr-Commit-Position: refs/heads/master@{#31293}
