Commit Graph

94 Commits

Author SHA1 Message Date
Mike Stanton
291dc3cd1f [Feedback Vector] Coalesce Nexii to Feedback Nexus.
The FeedbackNexus classes initially were one-to-one with IC classes,
but over time this got out of date. We also found Nexus' useful, so
we made more classes even for cases that weren't ICs.

The inheritence and polymorphism became confusing and led to
duplication. Better, to just talk about a (single) FeedbackNexus.

Bug: v8:7344
Change-Id: I509dc9657895d56c3859de6e6589695cdff9e73e
Reviewed-on: https://chromium-review.googlesource.com/890452
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50997}
2018-01-31 14:34:33 +00:00
Sigurd Schneider
47a81f0bd2 Add speculation mode to Call node
This patch adds a field for the speculation mode to Call
nodes, and passes the speculation mode from the CallIC
to the Call node in the byte code graph builder.

Bug: v8:7127
Change-Id: I89fa10643b46143b36776de1d5ba6ebe3fa2c878
Reviewed-on: https://chromium-review.googlesource.com/814537
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49965}
2017-12-08 14:51:10 +00:00
Sigurd Schneider
7be22a8c62 Use bits of call count on CallIC as flags
This CL uses bits of the call count as flags according
to CallCountField and SpeculationModeField defined in
CallICNexus.

Bug: v8:7127
Change-Id: I3f64c1807d61410f9029b46b9a59a1fcaa5a0a3b
Reviewed-on: https://chromium-review.googlesource.com/808926
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49959}
2017-12-08 13:31:03 +00:00
Ross McIlroy
ed592eb03f [Cleanup][Interpreter] Move feedback slot allocation to bytecode generator
Moves the feedback vector slot allocation out of ast-numbering and into
bytecode generation directly. This has a couple of benifits, including reduced
AST size, avoid code duplication and reduced feedback vector sizes in many cases
due to only allocating slots when needed. Also removes AstProperties since
this is no longer needed.

AstNumbering is now only used to allocate suspend ids for generators.

BUG=v8:6921

Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f
Reviewed-on: https://chromium-review.googlesource.com/722959
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 16:17:14 +00:00
Benedikt Meurer
f1ec44e2f5 [turbofan] Optimize fast enum cache driven for..in.
This CL adds support to optimize for..in in fast enum-cache mode to the
same degree that it was optimized in Crankshaft, without adding the same
deoptimization loop that Crankshaft had with missing enum cache indices.
That means code like

  for (var k in o) {
    var v = o[k];
    // ...
  }

and code like

  for (var k in o) {
    if (Object.prototype.hasOwnProperty.call(o, k)) {
      var v = o[k];
      // ...
    }
  }

which follows the https://eslint.org/docs/rules/guard-for-in linter
rule, can now utilize the enum cache indices if o has only fast
properties on the receiver, which speeds up the access o[k]
significantly and reduces the pollution of the global megamorphic
stub cache.

For example the micro-benchmark in the tracking bug v8:6702 now runs
faster than ever before:

 forIn: 1516 ms.
 forInHasOwnProperty: 1674 ms.
 forInHasOwnPropertySafe: 1595 ms.
 forInSum: 2051 ms.
 forInSumSafe: 2215 ms.

Compared to numbers from V8 5.8 which is the last version running with
Crankshaft

 forIn: 1641 ms.
 forInHasOwnProperty: 1719 ms.
 forInHasOwnPropertySafe: 1802 ms.
 forInSum: 2226 ms.
 forInSumSafe: 2409 ms.

and V8 6.0 which is the current stable version with TurboFan:

 forIn: 1713 ms.
 forInHasOwnProperty: 5417 ms.
 forInHasOwnPropertySafe: 5324 ms.
 forInSum: 7556 ms.
 forInSumSafe: 11067 ms.

It also improves the throughput on the string-fasta benchmark by
around 7-10%, and there seems to be a ~5% improvement on the
Speedometer/React benchmark locally.

For this to work, the ForInPrepare bytecode was split into
ForInEnumerate and ForInPrepare, which is very similar to how it was
handled in Fullcodegen initially. In TurboFan we introduce a new
operator LoadFieldByIndex that does the dynamic property load.

This also removes the CheckMapValue operator again in favor of
just using LoadField, ReferenceEqual and CheckIf, which work
automatically with the EscapeAnalysis and the
BranchConditionElimination.

Bug: v8:6702
Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a
Reviewed-on: https://chromium-review.googlesource.com/645949
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47768}
2017-09-01 11:27:37 +00:00
Mostyn Bramley-Moore
cddbe282c6 Start preparing test/cctest for jumbo compilation
* Avoid "using namespace" statements, which trigger clang's -Wheader-hygiene
  warnings in jumbo builds.
* Undefine created macros at the end of source files.

BUG=chromium:746958

Change-Id: I5d25432c314437f607b0e1be22765a6764267ba6
Reviewed-on: https://chromium-review.googlesource.com/610962
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Cr-Commit-Position: refs/heads/master@{#47347}
2017-08-14 20:58:10 +00:00
Benedikt Meurer
448a1d4bb5 [ic] Drop Array constructor support from CallIC.
Calling the Array constructor is an edge case, and we don't seem to
benefit from doing the AllocationSite tracking there as well. In fact
it's a lot of complexity and somewhat blocking the more important 
optimization of the subclass constructors.

This is an attempt to nuke the CallIC support for AllocationSites. If
it regresses something important, we'll have to find another way.

Bug: v8:6399
Change-Id: I56f6da29679c516f0a5c3161c2696fc2b8762176
Reviewed-on: https://chromium-review.googlesource.com/600968
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47158}
2017-08-04 09:22:14 +00:00
Leszek Swirski
37680d6563 [objects] Make feedback vector a first-class object
Instead of having feedback vector as a subtype of FixedArray with
reserved slots, make it a first-class variable-sized object with a
fixed-size header. This allows us to compress counters to ints in the
header, rather than forcing them to be Smis.

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48
Reviewed-on: https://chromium-review.googlesource.com/585129
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46935}
2017-07-27 13:31:55 +00:00
danno
fc274fbe99 Unify implementations of Map handles vectors and lists
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}
2017-05-09 22:36:00 +00:00
Igor Sheludko
0cd4ab717c [ic] Remove disabled --collect-megamorphic-maps-from-stub-cache option.
... and stop checking that the native contexts of maps recorded in feedback vector
match function's native context - the feedback vector machinery already guarantees
that.

BUG=v8:6325

Change-Id: Iacd3f3a5f703694ff57b774b9658e186ad66641b
Reviewed-on: https://chromium-review.googlesource.com/490084
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44982}
2017-04-28 13:31:24 +00:00
Adam Klein
b3887f8a2c [cctest] Simplify the majority of callers of CcTest::CollectAllGarbage
Most callers passed kFinalizeIncrementalMarkingMask, so use that as
a default argument (not using default argument syntax to avoid including
heap.h in cctest.h).

Change-Id: I904f1eb3a0f5fdbe63eab16f6a6f01d04618645d
Reviewed-on: https://chromium-review.googlesource.com/488104
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44950}
2017-04-27 17:20:54 +00:00
Igor Sheludko
16c38aa820 [ic] Split StoreIC into StoreGlobalIC and StoreIC.
The former will handle stores to global variables, lets and undeclared
variables. The latter will handle named stores to explicit receiver.

BUG=chromium:576312, v8:5561

Change-Id: I335fa21db47c3d001da8cc79fa8cb6f8abcbb7e2
Reviewed-on: https://chromium-review.googlesource.com/458639
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44085}
2017-03-24 07:45:14 +00:00
Marja Hölttä
83849da70f [iwyu] Pre-work for removing unallowed include macro-assembler.h -> assembler-inl.h
BUG=v8:5294

Change-Id: If45f25aae8de526027b7851cb4efe0ccf4a7c4b1
Reviewed-on: https://chromium-review.googlesource.com/444226
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43388}
2017-02-23 12:10:21 +00:00
Igor Sheludko
a85f27d8a4 [ic] Introduce StoreOwnIC.
... which is used for initializing properties with non compile time values.

Currently we use StoreOwnIC only for storing properties that already exist
in the boilerplate therefore we can reuse StoreIC dispatcher.
The proper StoreOwnIC dispatcher will be implemented in a separate CL.

BUG=v8:5495, v8:4414

Change-Id: I9c33fdb8499ec5be2c7fce1ecb6ce7aa285e5844
Reviewed-on: https://chromium-review.googlesource.com/443588
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43285}
2017-02-17 15:55:33 +00:00
Igor Sheludko
fdc78d294e [ic] Cleanup vector-based IC clearing.
... and don't clear ICs during GC. The IC clearing used to prevent memory
leaks but it's not necessary anymore because all the handlers that need
to embed objects already use weak cells.

This CL unblocks inlining of IC dispatchers into bytecode handlers.

BUG=v8:5917

Change-Id: I229b9ba8dba44f431dfbe8ac5370d855e3e84dd6
Reviewed-on: https://chromium-review.googlesource.com/442127
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43209}
2017-02-15 13:01:11 +00:00
ishell@chromium.org
0190a00f96 [ic] Rename FeedbackSlotKind values to better reflect reality.
BUG=v8:5917

Change-Id: I9611ace4ba73f18cb90f95f9c81eeb19c74e06f4
Reviewed-on: https://chromium-review.googlesource.com/439327
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43032}
2017-02-08 10:49:58 +00:00
yangguo
c78d7fa1ae Link type feedback vectors to the shared function info.
Previously, both type feedback vector and the shared function info
of a function points to the matching type feedback metadata. This
makes finding the shared function info of a type feedback vector
difficult.

Instead, we now point the type feeback vector to the shared function
info, and find the metadata through the shared function info.

Also remove the obsolete empty type feedback vector.

R=hpayer@chromium.org, mvstanton@chromium.org
BUG=v8:5808

Review-Url: https://codereview.chromium.org/2672363002
Cr-Commit-Position: refs/heads/master@{#43026}
2017-02-08 08:33:33 +00:00
ishell@chromium.org
878a3df75e Rename FeedbackVectorSlot[Kind] -> FeedbackSlot[Kind].
BUG=

Change-Id: I31b8da09f4728d55c2da91966edcad49528b554b
Reviewed-on: https://chromium-review.googlesource.com/439146
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43003}
2017-02-07 16:38:47 +00:00
ishell@chromium.org
32971301ea Rename TypeFeedbackVector to FeedbackVector.
... and TypeFeedbackMetadata to FeedbackMetadata.

BUG=

Change-Id: I2556d1c2a8f37b8cf3d532cc98d973b6dc7e9e6c
Reviewed-on: https://chromium-review.googlesource.com/439244
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#42999}
2017-02-07 14:46:36 +00:00
ishell
ef4e2ab7bd [ic] Encode LoadGlobalIC's typeof mode in slot kind instead of code object's flags.
BUG=v8:5917

Review-Url: https://codereview.chromium.org/2673383002
Cr-Commit-Position: refs/heads/master@{#42982}
2017-02-07 09:03:16 +00:00
mvstanton
aea3ce3df3 [TypeFeedbackVector] Root feedback vectors at function literal site.
TypeFeedbackVectors are strongly rooted by a closure. However, in modern
JavaScript closures are created and abandoned more freely. An important
closure may not be present in the root-set at time of garbage collection,
even though we've cached optimized code and use it regularly. For
example, consider leaf functions in an event dispatching system. They may
well be "hot," but tragically non-present when we collect the heap.

Until now, we've relied on a weak root to cache the feedback vector in
this case. Since there is no way to signal intent or relative importance,
this weak root is as susceptible to clearing as any other weak root at
garbage collection time.

Meanwhile, the feedback vector has become more important. All of our
ICs store their data there. Literal and regex boilerplates are stored there.
If we lose the vector, then we not only lose optimized code built from
it, we also lose the very feedback which allowed us to create that optimized
code. Therefore it's vital to express that dependency through the root
set.

This CL does this by creating a strong link to a feedback
vector at the instantiation site of the function closure.
This instantiation site is in the code and feedback vector
of the outer closure.

BUG=v8:5456

Review-Url: https://codereview.chromium.org/2674593003
Cr-Commit-Position: refs/heads/master@{#42953}
2017-02-06 10:18:05 +00:00
ishell
52555c86b7 [ic] Encode [Keyed]StoreIC's language mode in slot kind instead of code object's flags.
BUG=v8:5917

Review-Url: https://codereview.chromium.org/2676583002
Cr-Commit-Position: refs/heads/master@{#42949}
2017-02-06 09:31:52 +00:00
mvstanton
93f05b64ae [TypeFeedbackVector] Combine the literals array and the feedback vector.
They have the same lifetime. It's a match!

Both structures are native context dependent and dealt with (creation,
clearing, gathering feedback) at the same time. By treating the spaces used
for literal boilerplates as feedback vector slots, we no longer have to keep
track of the materialized literal count elsewhere.

A follow-on CL removes even more parser infrastructure related to this count.

BUG=v8:5456

Review-Url: https://codereview.chromium.org/2655853010
Cr-Commit-Position: refs/heads/master@{#42771}
2017-01-30 12:31:35 +00:00
mvstanton
73980ae4a1 [TypeFeedbackVector] Remove unnecessary Parameters metadata
This is a remnant of a previous design to a solution yet to be
checked in.

BUG=v8:5456
R=bmeurer@chromium.org

Review-Url: https://codereview.chromium.org/2650853008
Cr-Commit-Position: refs/heads/master@{#42692}
2017-01-26 12:08:35 +00:00
mvstanton
55feaaea4c Revert [TypeFeedbackVector] Root literal arrays in function literal slots
GC performance issues need to be addressed first.

TBR=bmeurer@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org
BUG=v8:5456

Review-Url: https://codereview.chromium.org/2642743002
Cr-Original-Commit-Position: refs/heads/master@{#42495}
Committed: 7803aa1ffb
Review-Url: https://codereview.chromium.org/2642743002
Cr-Commit-Position: refs/heads/master@{#42517}
2017-01-19 17:12:28 +00:00
machenbach
a8f2890757 Revert of Revert [TypeFeedbackVector] Root literal arrays in function literal slots (patchset #2 id:20001 of https://codereview.chromium.org/2642743002/ )
Reason for revert:
Breaks nosnap:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap/builds/13802

Original issue's description:
> Revert [TypeFeedbackVector] Root literal arrays in function literal slots
>
> GC performance issues need to be addressed first.
>
> TBR=bmeurer@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org
> BUG=v8:5456
>
> Review-Url: https://codereview.chromium.org/2642743002
> Cr-Commit-Position: refs/heads/master@{#42495}
> Committed: 7803aa1ffb

TBR=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/2642933003
Cr-Commit-Position: refs/heads/master@{#42496}
2017-01-19 12:01:36 +00:00
mvstanton
7803aa1ffb Revert [TypeFeedbackVector] Root literal arrays in function literal slots
GC performance issues need to be addressed first.

TBR=bmeurer@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org
BUG=v8:5456

Review-Url: https://codereview.chromium.org/2642743002
Cr-Commit-Position: refs/heads/master@{#42495}
2017-01-19 10:38:04 +00:00
mvstanton
b8294aaa97 [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/2620753003
Cr-Original-Commit-Position: refs/heads/master@{#42258}
Committed: 3188780410
Review-Url: https://codereview.chromium.org/2620753003
Cr-Commit-Position: refs/heads/master@{#42264}
2017-01-12 11:29:09 +00:00
machenbach
3d9e2ea32d Revert of [TypeFeedbackVector] Root literal arrays in function literals slots (patchset #7 id:120001 of https://codereview.chromium.org/2620753003/ )
Reason for revert:
gc stress:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/8105

also on mac

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/2620753003
> Cr-Commit-Position: refs/heads/master@{#42258}
> Committed: 3188780410

TBR=bmeurer@chromium.org,mstarzinger@chromium.org,yangguo@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/2626863004
Cr-Commit-Position: refs/heads/master@{#42260}
2017-01-12 10:10:56 +00:00
mvstanton
3188780410 [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/2620753003
Cr-Commit-Position: refs/heads/master@{#42258}
2017-01-12 09:28:48 +00:00
mvstanton
38602f1ff5 [FeedbackVector] Infrastructure for literal arrays in the vector.
This changes the NewClosure interface descriptor, but ignores
the additional vector/slot arguments for now. The feedback vector
gets larger, as it holds a space for each literal array. A follow-on
CL will constructively use this space.

BUG=v8:5456

Review-Url: https://codereview.chromium.org/2614373002
Cr-Commit-Position: refs/heads/master@{#42146}
2017-01-09 15:31:00 +00:00
hablich
aa8a208a47 Revert of [TypeFeedbackVector] Root literal arrays in function literals slots (patchset #11 id:370001 of https://codereview.chromium.org/2504153002/ )
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: 93df094081

TBR=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}
2016-12-22 10:26:36 +00:00
mvstanton
93df094081 [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}
2016-12-21 14:06:29 +00:00
heimbuef
e7fa9b0129 Named all zones in the project
This adds more useful information to the v8-heap-stats tool.

BUG=v8:5489

Review-Url: https://codereview.chromium.org/2394213003
Cr-Commit-Position: refs/heads/master@{#40361}
2016-10-17 12:12:42 +00:00
mvstanton
b88d132f4c [TypeFeedbackVector] special ic slots for interpreter compare/binary ops.
Full code uses patching ICs for this feedback, and the interpreter uses
the type feedback vector. It's a good idea to code the vector slots
appropriately as ICs so that the runtime profiler can better gauge if
the function is ready for tiering up from Ignition to TurboFan.

As is, the feedback is stored in "general" slots which can't be
characterized by the runtime profiler into feedback states.

This CL addresses that problem. Note that it's also important to
carefully exclude these slots from the profiler's consideration when
determining if you want to optimize from Full code.

BUG=

Review-Url: https://codereview.chromium.org/2342853002
Cr-Commit-Position: refs/heads/master@{#39555}
2016-09-20 13:54:51 +00:00
bmeurer
c7d7ca361d [turbofan] Collect invocation counts and compute relative call frequencies.
Add a notion of "invocation count" to the baseline compilers, which
increment a special slot in the TypeFeedbackVector for each invocation
of a given function (the optimized code doesn't currently collect this
information).

Use this invocation count to relativize the call counts on the call
sites within the function, so that the inlining heuristic has a view
of relative importance of a call site rather than some absolute numbers
with unclear meaning for the current function. Also apply the call site
frequency as a factor to all frequencies in the inlinee by passing this
to the graph builders so that the importance of a call site in an
inlinee is relative to the topmost optimized function.

Note that all functions that neither have literals nor need type
feedback slots will share a single invocation count cell in the
canonical empty type feedback vector, so their invocation count is
meaningless, but that doesn't matter since we only use the invocation
count to relativize call counts within the function, which we only have
if we have at least one type feedback vector (the CallIC slot).

See the design document for additional details on this change:
https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8

BUG=v8:5267,v8:5372
R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org

Review-Url: https://codereview.chromium.org/2337123003
Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:48 +00:00
mvstanton
3ccedd5d8a CallConstruct also gets call count information if megamorphic.
BUG=

Review-Url: https://codereview.chromium.org/2333243004
Cr-Commit-Position: refs/heads/master@{#39398}
2016-09-14 03:23:51 +00:00
mvstanton
2ab3fcf42f Record call counts also for megamorphic calls.
To make better inlining decisions, it's good to have call counts for poly/mega-morphic cases. This CL makes it work for calls, and another will follow to better unify the code between constructor calls and normal calls (and thence, to record megamorphic call counts there as well).

BUG=

Review-Url: https://codereview.chromium.org/2325083003
Cr-Commit-Position: refs/heads/master@{#39377}
2016-09-13 11:04:22 +00:00
ulan
1b26611ce9 [heap] Introduce enum of garbage collection reasons.
Now callers of Heap::CollectGarbage* functions need to
specify the reason as an enum value instead of a string.

Subsequent CL will add stats counter for GC reason.

BUG=

Review-Url: https://codereview.chromium.org/2310143002
Cr-Commit-Position: refs/heads/master@{#39239}
2016-09-07 10:03:08 +00:00
mythria
9e3e2ee2dd [Interpreter] Assign feedback slots for binary operations and use them in ignition.
Assign feedback slots in the type feedback vector for binary operations.
Update bytecode-generator to use these slots and add them as an operand
to binary operations.

BUG=v8:4280
LOG=N

Review-Url: https://codereview.chromium.org/2209633002
Cr-Commit-Position: refs/heads/master@{#38408}
2016-08-08 01:16:40 +00:00
mstarzinger
7f6839d642 [test] Remove uses of runtime zone from tests.
R=mvstanton@chromium.org

Review-Url: https://codereview.chromium.org/2190623002
Cr-Commit-Position: refs/heads/master@{#38115}
2016-07-28 08:06:14 +00:00
mythria
fd420203ec [Interpreter] Collect type feedback for calls in the bytecode handler
Collect type feedback in the call bytecode handler. The current
implementation only collects feedback for JS function objects. The other
objects and Array functions do not collect any feedback. They will be
marked Megamorphic.

BUG=v8:4280, v8:4780
LOG=N

Review-Url: https://codereview.chromium.org/2122183002
Cr-Commit-Position: refs/heads/master@{#37700}
2016-07-13 08:00:23 +00:00
ishell
d9e8764f81 [ic] Split LoadIC into LoadGlobalIC and LoadIC.
The former will handle loads of predeclared global variables (vars and
functions), lets, consts and undeclared variables. The latter will handle
named loads from explicit receiver. In addition, named loads does not
depend of the TypeofMode.

TypeofMode related cleanup will be done in the follow-up CL.

BUG=chromium:576312
LOG=Y
TBR=bmeurer@chromium.org

Review-Url: https://codereview.chromium.org/1912633002
Cr-Commit-Position: refs/heads/master@{#36965}
2016-06-14 13:21:28 +00:00
mvstanton
91c88644dc Move of the type feedback vector to 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.

BUG=

Review-Url: https://codereview.chromium.org/1906823002
Cr-Commit-Position: refs/heads/master@{#36539}
2016-05-27 08:10:51 +00:00
mvstanton
a6ddbef064 Collect call counts for constructor calls, too.
The TurboFan inliner makes use of these counts.

BUG=

Review-Url: https://codereview.chromium.org/1969783002
Cr-Commit-Position: refs/heads/master@{#36472}
2016-05-24 11:53:45 +00:00
mvstanton
3f36e658c8 Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of https://codereview.chromium.org/1668103002/ )
Reason for revert:
Must revert for now due to chromium api natives issues.

Original issue's description:
> Type Feedback Vector lives in the closure
>
> (RELAND: the problem before was a missing write barrier for adding the code
> entry to the new closure. It's been addressed with a new macro instruction
> and test. The only change to this CL is the addition of two calls to
> __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
>
> 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...
> Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
> And Benedikt reviewed it as well.
>
> TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5
> Cr-Commit-Position: refs/heads/master@{#33741}

TBR=bmeurer@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/1670813005

Cr-Commit-Position: refs/heads/master@{#33766}
2016-02-05 10:48:35 +00:00
mvstanton
bb31db3ad6 Type Feedback Vector lives in the closure
(RELAND: the problem before was a missing write barrier for adding the code
entry to the new closure. It's been addressed with a new macro instruction
and test. The only change to this CL is the addition of two calls to
__ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)

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...
Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
And Benedikt reviewed it as well.

TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org

BUG=

Review URL: https://codereview.chromium.org/1668103002

Cr-Commit-Position: refs/heads/master@{#33741}
2016-02-04 15:41:23 +00:00
mvstanton
a702785156 Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of https://codereview.chromium.org/1642613002/ )
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}
2016-01-27 15:05:38 +00:00
mvstanton
d984b3b0ce 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=

Review URL: https://codereview.chromium.org/1642613002

Cr-Commit-Position: refs/heads/master@{#33548}
2016-01-27 12:53:42 +00:00
mvstanton
e2e7dc32ef Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of https://codereview.chromium.org/1563213002/ )
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}
2016-01-26 15:02:29 +00:00