Commit Graph

63 Commits

Author SHA1 Message Date
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
mvstanton
a5200f7ed4 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=

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

Cr-Commit-Position: refs/heads/master@{#33518}
2016-01-26 14:21:08 +00:00
jochen
6f472db65a Disable soon to be deprecated APIs per default for v8
Embedders still can use those APIs by default

test-api.cc still has an exception to use the old APIs...

BUG=v8:4143
R=vogelheim@chromium.org
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#32701}
2015-12-09 10:35:04 +00:00
mvstanton
2b63d6b079 Type Feedback Vector: Calculate profiler counts on the fly.
It's cumbersome to maintain IC profiler statistics all the time.
Let's just do it as needed.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#32693}
2015-12-09 08:33:21 +00:00
mvstanton
e75e625453 VectorICs: Remove --vector-stores flag.
BUG=

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

Cr-Commit-Position: refs/heads/master@{#32040}
2015-11-17 13:15:52 +00:00
mvstanton
f714e4831a Remove deprecated APIs from cctest/test-feedback-vector
BUG=

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

Cr-Commit-Position: refs/heads/master@{#31562}
2015-10-26 13:10:29 +00:00
jochen
5587656155 Map v8::Function to JSReceiver + IsCallable
BUG=none
LOG=y
R=verwaest@chromium.org,bmeurer@chromium.org,rossberg@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng

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

Cr-Commit-Position: refs/heads/master@{#31519}
2015-10-23 12:27:06 +00:00
ishell
1d7c9c8139 The metadata part of TypeFeedbackVector is extracted to TypeFeedbackMetadata array.
Thus TypeFeedbackMetadata can now be shared between different native contexts.

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

Cr-Commit-Position: refs/heads/master@{#31143}
2015-10-07 10:33:32 +00:00
ishell
90998947bc Distinction between FeedbackVectorICSlot and FeedbackVectorSlot eliminated.
This CL also allows to use arbitrary number of feedback vector elements for particular slot kind.

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

Cr-Commit-Position: refs/heads/master@{#31050}
2015-10-01 13:48:19 +00:00
mstarzinger
6a769ac1df [presubmit] Enable readability/namespace linter checking.
This enables linter checking for "readability/namespace" violations
during presubmit and instead marks the few known exceptions that we
allow explicitly.

R=bmeurer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#31019}
2015-09-30 13:47:11 +00:00
ishell
b2d82a22a1 Refactored interface of FeedbackVectorSpec and friends.
This is a second step towards merging FeedbackVectorSlot and FeedbackVectorICSlot.

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

Cr-Commit-Position: refs/heads/master@{#30971}
2015-09-28 11:41:48 +00:00
ishell
6ca00aac1a Use FeedbackVectorSlotKind instead of Code::Kind for type feedback vector.
This is a first step towards merging FeedbackVectorSlot and FeedbackVectorICSlot.

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

Cr-Commit-Position: refs/heads/master@{#30964}
2015-09-28 08:23:50 +00:00
mvstanton
40fbed0609 Reland Vector ICs: platform support for vector-based stores.
The last changes for vector store functionality, they are in 3 areas:

1) The new vector [keyed] store code stubs - implementation.
2) IC and handler compiler adjustments
3) Odds and ends. A change in ast.cc, a test update, a small Oracle fix.

TBR=bmeurer@chromium.org, jkummerow@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#30581}
2015-09-04 08:36:43 +00:00
machenbach
d51c588524 Revert of Vector ICs: platform support for vector-based stores. (patchset #7 id:120001 of https://codereview.chromium.org/1328603003/ )
Reason for revert:
[Sheriff] Breaks compile on arm:
http://build.chromium.org/p/client.v8/builders/V8%20Arm%20-%20builder/builds/6590

Original issue's description:
> Vector ICs: platform support for vector-based stores.
>
> The last changes for vector store functionality, they are in 3 areas:
>
> 1) The new vector [keyed] store code stubs - implementation.
> 2) IC and handler compiler adjustments
> 3) Odds and ends. A change in ast.cc, a test update, a small Oracle fix.
>
> BUG=
>
> Committed: https://crrev.com/63af1b3aec6547e7cdf502666ff79c562de8b679
> Cr-Commit-Position: refs/heads/master@{#30570}

TBR=bmeurer@chromium.org,jkummerow@chromium.org,mvstanton@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

Cr-Commit-Position: refs/heads/master@{#30571}
2015-09-03 17:44:32 +00:00
mvstanton
63af1b3aec Vector ICs: platform support for vector-based stores.
The last changes for vector store functionality, they are in 3 areas:

1) The new vector [keyed] store code stubs - implementation.
2) IC and handler compiler adjustments
3) Odds and ends. A change in ast.cc, a test update, a small Oracle fix.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#30570}
2015-09-03 17:18:24 +00:00
mvstanton
1a5751f9b3 VectorICs: refactoring to eliminate "for queries only" vector ic mode.
Since we need the notion of a dummy vector ic, we can use that to avoid
a special case of the IC constructor. Also, consolidate the two dummy
ICs into one.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#29956}
2015-07-31 14:04:13 +00:00
yangguo
1667c15e37 Debugger: move implementation to a separate folder.
R=cbruni@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#29951}
2015-07-31 11:08:15 +00:00
mvstanton
f469b21143 Stop overallocating feedback vector slots.
When a Property or a VariableProxy is used as the left hand side of an
assignment statement, there is no need to allocate a LOAD_IC feedback
vector slot for it. Alter the numbering phase to support this.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#29924}
2015-07-30 10:38:04 +00:00
ishell
8fe17a6780 Support for global var shortcuts in script contexts.
Review URL: https://codereview.chromium.org/1218783005

Cr-Commit-Position: refs/heads/master@{#29498}
2015-07-06 16:36:39 +00:00
arv
345fa142a9 Refactor lexical home object binding
Before this we had 3 super related lexical bindings that got injected
into method bodies: .home_object, .this_function,  and new.target.
With this change we get rid of the .home_object one in favor of using
.this_function[home_object_symbol] which allows some simplifications
throughout the code base.

BUG=v8:3768
LOG=N
R=adamk@chromium.org, wingo@igalia.com

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

Cr-Commit-Position: refs/heads/master@{#28802}
2015-06-04 16:22:41 +00:00
arv
44e9810345 [es6] Support super.property in eval and arrow functions
When we enter a method that needs access to the [[HomeObject]]
we allocate a local variable `.home_object` and assign it the
value from the [[HomeObject]] private symbol. Something along
the lines of:

  method() {
    var .home_object = %ThisFunction()[home_object_symbol];
    ...
  }

BUG=v8:3867, v8:4031
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#28644}
2015-05-26 20:29:54 +00:00
mvstanton
323ced9e27 Now that vector ics are established for load, keyed load and call ics, let's remove dead code behind the flag.
BUG=

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

Cr-Commit-Position: refs/heads/master@{#28422}
2015-05-15 13:25:22 +00:00
hpayer
ee59bde703 Reland Force full GCwhenever CollectAllGarbage is meant to trigger a full GC.
BUG=

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

Cr-Commit-Position: refs/heads/master@{#28024}
2015-04-23 08:37:05 +00:00
machenbach
301151545e Revert of Force full GCwhenever CollectAllGarbage is meant to trigger a full GC. (patchset #4 id:60001 of https://codereview.chromium.org/1082973003/)
Reason for revert:
[Sheriff] Breaks http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/3348 and maybe leads to timeouts/crashes on layout test bots:
http://build.chromium.org/p/client.v8/builders/V8-Blink%20Linux%2064/builds/3002

Original issue's description:
> Force full GC whenever CollectAllGarbage is meant to trigger a full GC.
>
> Add a finalize incremental marking mode for CollectAllGarbage to finalize incremental marking when incremental marking is in progress, but we want a full gc at a given CollectAllGarbage call site.
>
> Default mode for CollectAllGarbage is finalize incremental marking and perform a full GC.
>
> BUG=
>
> Committed: https://crrev.com/9c105f0940ba757364ac18fcdf649815ec5ab2d1
> Cr-Commit-Position: refs/heads/master@{#27831}

TBR=ulan@chromium.org,hpayer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

Cr-Commit-Position: refs/heads/master@{#27834}
2015-04-15 09:07:21 +00:00
hpayer
9c105f0940 Force full GC whenever CollectAllGarbage is meant to trigger a full GC.
Add a finalize incremental marking mode for CollectAllGarbage to finalize incremental marking when incremental marking is in progress, but we want a full gc at a given CollectAllGarbage call site.

Default mode for CollectAllGarbage is finalize incremental marking and perform a full GC.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#27831}
2015-04-15 07:10:39 +00:00
mvstanton
b134ae74b5 v8:3539 - hold constructor feedback in weak cells
BUG=v8:3539
R=verwaest@chromium.org
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#27581}
2015-04-02 09:39:35 +00:00
mvstanton
7478c5a0cc Feedback vector: ASAN found memory leaks during AST Numbering pass.
The cause was dynamic allocation of an accounting structure used to
create/initialize the type feedback vector, done at the end of the
numbering pass. The solution is to Zone-allocate the structure to
bring it's lifetime in line with the compilation unit.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#27241}
2015-03-17 15:16:36 +00:00
mvstanton
34a1a76ddf Use platform specific stubs for vector-based Load/KeyedLoad.
A hydrogen code stub is not the best approach because it builds a frame
and doesn't have the technology to discard roots at tail call exits.
Platform-specific stubs provide much better performance at this point.

R=verwaest@chromium.org

BUG=

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

Cr-Commit-Position: refs/heads/master@{#27235}
2015-03-17 11:28:21 +00:00
mvstanton
4ededa8694 Vector-ICs: Implement slot sharing for global loads.
We can reduce the number of type feedback vector slots required, and
also reduce IC misses.

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

Cr-Commit-Position: refs/heads/master@{#27149}
2015-03-12 09:23:01 +00:00
mvstanton
6fc97a1965 Retry "Use a WeakCell in the CallIC type vector."
The first try failed because I needed to make a better distinction
between clearing ICs according to policy at GC time or unconditional
clearing (say, via %ClearFunctionTypeFeedback).

It was also blocked by an issue in super constructor calls.
This fix (https://codereview.chromium.org/892113002/) needs to land
before checking in this CL.

R=ulan@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#26420}
2015-02-04 09:46:22 +00:00
bmeurer
c65ae4f10c Reland "Initial switch to Chromium-style CHECK_* and DCHECK_* macros.".
R=svenpanne@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#26346}
2015-01-30 09:29:41 +00:00
Benedikt Meurer
883852293a Revert "Make GCC happy again." and "Initial switch to Chromium-style CHECK_* and DCHECK_* macros.".
This reverts commit 6a4c0a3bae and commit
0deaa4b629 for breaking GCC bots.

TBR=svenpanne@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#26342}
2015-01-30 07:19:57 +00:00