[TypeFeedbackVector] Root literal arrays in function literals slots

[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: https://chromium.googlesource.com/v8/v8/+/31887804107bf5c103d915f5c601cfaaf1cd7cb6
Review-Url: https://codereview.chromium.org/2620753003
Cr-Commit-Position: refs/heads/master@{#42264}
Committed: https://chromium.googlesource.com/v8/v8/+/b8294aaa978e972978b8d82cedf63befad5d7af1

[mvstanton, 2017-01-10 12:36:00]

Description was changed from

==========
[TypeFeedbackVector] Root literal arrays in outer vector.

BUG=v8:5456
==========

to

==========
[TypeFeedbackVector] Root literal arrays in outer vector.


Currently, this CL has a fix for an issue in ia32 and x64 CompileLazy
builtin. The issue is with evals whose scripts die, but the 
optimized code inside the eval is cached.

BUG=v8:5456
==========

[mvstanton, 2017-01-10 12:36:00]

mvstanton@chromium.org changed reviewers:
+ bmeurer@chromium.org

[mvstanton, 2017-01-10 20:09:56]

The CQ bit was checked by mvstanton@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-10 20:10:00]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-10 20:14:29]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-10 20:14:30]

Dry run: Try jobs failed on following builders:
  v8_linux_mips64el_compile_rel on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_mips64el_compile_r...)

[mvstanton, 2017-01-10 20:17:05]

Hi Benedikt, here is the rest of the literals CL, now with a fix applied in
CompileLazy for the necessary check if our feedback vector is valid. Also, I
added a repro test for the bug at the bottom of strong-rooted-literals.js.

A later CL will provide a more nuanced fix here, following on a discussion with
Toon and Michi today. That fix involves removal of the optimized code map and
storing opt. code in the vector.

Thanks!
--Michael

[mvstanton, 2017-01-10 20:21:16]

The CQ bit was checked by mvstanton@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-10 20:21:20]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-10 20:49:58]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-10 20:49:59]

Dry run: This issue passed the CQ dry run.

[Benedikt Meurer, 2017-01-11 05:07:23]

Description was changed from

==========
[TypeFeedbackVector] Root literal arrays in outer vector.


Currently, this CL has a fix for an issue in ia32 and x64 CompileLazy
builtin. The issue is with evals whose scripts die, but the 
optimized code inside the eval is cached.

BUG=v8:5456
==========

to

==========
[TypeFeedbackVector] Root literal arrays in outer vector.

Currently, this CL has a fix for an issue in ia32 and x64 CompileLazy
builtin. The issue is with evals whose scripts die, but the 
optimized code inside the eval is cached.

BUG=v8:5456
==========

[Benedikt Meurer, 2017-01-11 05:11:21]

bmeurer@chromium.org changed reviewers:
+ mstarzinger@chromium.org, yangguo@chromium.org

[Benedikt Meurer, 2017-01-11 05:11:21]

bmeurer@chromium.org changed required reviewers:
+ mstarzinger@chromium.org, yangguo@chromium.org

[Benedikt Meurer, 2017-01-11 05:11:21]

LGTM from my side. Should get signoff from mstarzinger@ for compiler.cc related
changes and yangguo@ for debugger (just to be sure).

https://codereview.chromium.org/2620753003/diff/40001/src/compiler/js-create-...
File src/compiler/js-create-lowering.cc (right):

https://codereview.chromium.org/2620753003/diff/40001/src/compiler/js-create-...
src/compiler/js-create-lowering.cc:775: // remove EmptyLiteralsArrayConstant()
from jsgraph().
Nit: Address this TODO in this CL.

[mvstanton, 2017-01-11 06:34:27]

The CQ bit was checked by mvstanton@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-11 06:34:33]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[mvstanton, 2017-01-11 06:47:44]

Thank you.

Yang, Michael - this CL is a reland of the 2nd half of the "Ember Deopt"
literals work we've discussed occasionally. Special notes:

Yang - we'll be able to remove the empty_literals_array when this CL sticks. 

Michael - pipeline changes reflect that EnsureLiterals now has another behavior,
that if the literals array is already set, it may need to create the feedback
vector. The last test case in strong-rooted-literals.js shows the bug case found
by Chrome Clusterfuzz. I tried integrating a follow on CL which a) moves
optimized code to the vector and b) establishes the literals array as a key in
the context-specific OSR'd code map, but it creates a change bigger than I'd
like for one CL. I'll have that ready to go in the following days.

In the meantime, the issue we discussed yesterday (you can end up running
optimized code with one vector embedded while your closure points to a newly
created one thanks to a new script) is something that happens already in
production, since the cached literals array is only weakly held. It'll be cool
to set it up so that can't happen.

Thanks everyone,
--Michael

https://codereview.chromium.org/2620753003/diff/40001/src/compiler/js-create-...
File src/compiler/js-create-lowering.cc (right):

https://codereview.chromium.org/2620753003/diff/40001/src/compiler/js-create-...
src/compiler/js-create-lowering.cc:775: // remove EmptyLiteralsArrayConstant()
from jsgraph().
On 2017/01/11 05:11:21, Benedikt Meurer wrote:
> Nit: Address this TODO in this CL.

Done.

[mvstanton, 2017-01-11 06:49:15]

Description was changed from

==========
[TypeFeedbackVector] Root literal arrays in outer vector.

Currently, this CL has a fix for an issue in ia32 and x64 CompileLazy
builtin. The issue is with evals whose scripts die, but the 
optimized code inside the eval is cached.

BUG=v8:5456
==========

to

==========
[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
==========

[commit-bot: I haz the power, 2017-01-11 07:02:19]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-11 07:02:20]

Dry run: This issue passed the CQ dry run.

[Michael Starzinger, 2017-01-11 12:07:27]

Looking good, just minor things.

https://codereview.chromium.org/2620753003/diff/60001/src/objects-printer.cc
File src/objects-printer.cc (left):

https://codereview.chromium.org/2620753003/diff/60001/src/objects-printer.cc#...
src/objects-printer.cc:811: break;
Looks like accidental deletion. I think this is a real bug.

https://codereview.chromium.org/2620753003/diff/60001/src/objects.h
File src/objects.h (right):

https://codereview.chromium.org/2620753003/diff/60001/src/objects.h#newcode5012
src/objects.h:5012: inline bool needs_feedback_vector() const;
suggestion: Could we negate this predicate and call it "has_feedback_vector"
instead? The current naming makes it sound like the predicate is answering the
question whether this literals arrays "will ever need a feedback vector" whereas
it actually determines whether the literals array is "currently still missing"
one. WDYT?

https://codereview.chromium.org/2620753003/diff/60001/src/objects.h#newcode7211
src/objects.h:7211: MaybeHandle<Code> code,
Is there still a call-site left that does not pass a code? Otherwise we could
turn this into Handle<Code> instead and also drop the second sentence in the
comment above.

https://codereview.chromium.org/2620753003/diff/60001/src/objects.h#newcode8373
src/objects.h:8373: inline bool needs_literals_array() const;
suggestion: Likewise, I propose changing to "has_literals_array". Also I would
be OK with making this public and moving it close to the {JSFunction::literals}
accessor.

[mvstanton, 2017-01-11 13:14:52]

Thanks, Michael, comments addressed!
--Michael

https://codereview.chromium.org/2620753003/diff/60001/src/objects-printer.cc
File src/objects-printer.cc (left):

https://codereview.chromium.org/2620753003/diff/60001/src/objects-printer.cc#...
src/objects-printer.cc:811: break;
On 2017/01/11 12:07:27, Michael Starzinger wrote:
> Looks like accidental deletion. I think this is a real bug.

yowza, thanks!

https://codereview.chromium.org/2620753003/diff/60001/src/objects.h
File src/objects.h (right):

https://codereview.chromium.org/2620753003/diff/60001/src/objects.h#newcode5012
src/objects.h:5012: inline bool needs_feedback_vector() const;
On 2017/01/11 12:07:27, Michael Starzinger wrote:
> suggestion: Could we negate this predicate and call it "has_feedback_vector"
> instead? The current naming makes it sound like the predicate is answering the
> question whether this literals arrays "will ever need a feedback vector"
whereas
> it actually determines whether the literals array is "currently still missing"
> one. WDYT?

Good idea, done.

https://codereview.chromium.org/2620753003/diff/60001/src/objects.h#newcode7211
src/objects.h:7211: MaybeHandle<Code> code,
On 2017/01/11 12:07:27, Michael Starzinger wrote:
> Is there still a call-site left that does not pass a code? Otherwise we could
> turn this into Handle<Code> instead and also drop the second sentence in the
> comment above.

Good idea, done!

https://codereview.chromium.org/2620753003/diff/60001/src/objects.h#newcode8373
src/objects.h:8373: inline bool needs_literals_array() const;
On 2017/01/11 12:07:27, Michael Starzinger wrote:
> suggestion: Likewise, I propose changing to "has_literals_array". Also I would
> be OK with making this public and moving it close to the
{JSFunction::literals}
> accessor.

Done.

[mvstanton, 2017-01-11 13:15:03]

The CQ bit was checked by mvstanton@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-11 13:15:07]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Michael Starzinger, 2017-01-11 13:22:44]

LGTM from my end. Just nits left. Cool stuff!

https://codereview.chromium.org/2620753003/diff/80001/src/objects.cc
File src/objects.cc (right):

https://codereview.chromium.org/2620753003/diff/80001/src/objects.cc#newcode1...
src/objects.cc:12547: DCHECK(code.is_null() || code->kind() ==
Code::OPTIMIZED_FUNCTION);
nit: First half of the predicate should always hold now AFAICT.

https://codereview.chromium.org/2620753003/diff/80001/src/objects.cc#newcode1...
src/objects.cc:12567: if (!code.is_null()) {
nit: Should always hold now AFAICT.

https://codereview.chromium.org/2620753003/diff/80001/src/objects.cc#newcode1...
src/objects.cc:12598: Handle<WeakCell> code_cell = code.is_null()
nit: Should always hold now AFAICT.

https://codereview.chromium.org/2620753003/diff/80001/src/objects.h
File src/objects.h (right):

https://codereview.chromium.org/2620753003/diff/80001/src/objects.h#newcode5011
src/objects.h:5011: // Returns true if the vector isn't yet installed.
nit: Comment no longer applies (I would be fine with dropping the comment
completely now that semantics have been simplified).

[commit-bot: I haz the power, 2017-01-11 13:50:02]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-11 13:50:02]

Dry run: This issue passed the CQ dry run.

[mvstanton, 2017-01-11 14:10:56]

The CQ bit was checked by mvstanton@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-11 14:11:00]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-11 14:43:20]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-11 14:43:21]

Dry run: This issue passed the CQ dry run.

[mvstanton, 2017-01-11 14:52:06]

Thanks!

https://codereview.chromium.org/2620753003/diff/80001/src/objects.cc
File src/objects.cc (right):

https://codereview.chromium.org/2620753003/diff/80001/src/objects.cc#newcode1...
src/objects.cc:12547: DCHECK(code.is_null() || code->kind() ==
Code::OPTIMIZED_FUNCTION);
On 2017/01/11 13:22:44, Michael Starzinger wrote:
> nit: First half of the predicate should always hold now AFAICT.

Done.

https://codereview.chromium.org/2620753003/diff/80001/src/objects.cc#newcode1...
src/objects.cc:12567: if (!code.is_null()) {
On 2017/01/11 13:22:44, Michael Starzinger wrote:
> nit: Should always hold now AFAICT.

Done.

https://codereview.chromium.org/2620753003/diff/80001/src/objects.cc#newcode1...
src/objects.cc:12598: Handle<WeakCell> code_cell = code.is_null()
On 2017/01/11 13:22:44, Michael Starzinger wrote:
> nit: Should always hold now AFAICT.

Done.

https://codereview.chromium.org/2620753003/diff/80001/src/objects.h
File src/objects.h (right):

https://codereview.chromium.org/2620753003/diff/80001/src/objects.h#newcode5011
src/objects.h:5011: // Returns true if the vector isn't yet installed.
On 2017/01/11 13:22:44, Michael Starzinger wrote:
> nit: Comment no longer applies (I would be fine with dropping the comment
> completely now that semantics have been simplified).

Done.

[mvstanton, 2017-01-11 23:27:43]

The CQ bit was checked by mvstanton@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-11 23:27:54]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-11 23:30:04]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-11 23:30:05]

Dry run: This issue passed the CQ dry run.

[Yang, 2017-01-12 08:17:56]

LGTM with a comment.

https://codereview.chromium.org/2620753003/diff/100001/src/debug/liveedit.cc
File src/debug/liveedit.cc (right):

https://codereview.chromium.org/2620753003/diff/100001/src/debug/liveedit.cc#...
src/debug/liveedit.cc:892: if (!fun->shared()->is_compiled()) return;
Can we do some more preliminary filtering here? I think we only have to look at
the outer function? And in case of multiple functions sharing the same type
feedback vector, we only have to iterate it once?

How about we find the outer shared function info by iterating the shared
function infos of the same script, then hold onto the type feedback metadata.
Then we iterate the heap for all type feedback vectors and patch those that
match this type feedback metadata?

In a separate CL would be fine too.

[mvstanton, 2017-01-12 08:44:54]

thanks Yang!
--Michael

https://codereview.chromium.org/2620753003/diff/100001/src/debug/liveedit.cc
File src/debug/liveedit.cc (right):

https://codereview.chromium.org/2620753003/diff/100001/src/debug/liveedit.cc#...
src/debug/liveedit.cc:892: if (!fun->shared()->is_compiled()) return;
On 2017/01/12 08:17:56, Yang wrote:
> Can we do some more preliminary filtering here? I think we only have to look
at
> the outer function? And in case of multiple functions sharing the same type
> feedback vector, we only have to iterate it once?
> 
> How about we find the outer shared function info by iterating the shared
> function infos of the same script, then hold onto the type feedback metadata.
> Then we iterate the heap for all type feedback vectors and patch those that
> match this type feedback metadata?
> 
> In a separate CL would be fine too.

Sounds like a great idea. I will follow up with another CL for that...certainly
less expensive.

[mvstanton, 2017-01-12 08:45:05]

The CQ bit was checked by mvstanton@chromium.org

[mvstanton, 2017-01-12 08:45:06]

The patchset sent to the CQ was uploaded after l-g-t-m from
bmeurer@chromium.org, mstarzinger@chromium.org
Link to the patchset: https://codereview.chromium.org/2620753003/#ps100001
(title: "Moar comments.")

[commit-bot: I haz the power, 2017-01-12 08:45:12]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-12 08:47:31]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-12 08:47:32]

Failed to apply patch for src/compiler.cc:
While running git apply --index -p1;
  error: patch failed: src/compiler.cc:546
  error: src/compiler.cc: patch does not apply

Patch:       src/compiler.cc
Index: src/compiler.cc
diff --git a/src/compiler.cc b/src/compiler.cc
index
38c8d69691d54fe0ff936537f893fe46d289f2a1..606b34027ac193f29676ff42f0f389d89e2367f9
100644
--- a/src/compiler.cc
+++ b/src/compiler.cc
@@ -517,14 +517,13 @@ MUST_USE_RESULT MaybeHandle<Code>
GetCodeFromOptimizedCodeMap(
       &RuntimeCallStats::CompileGetFromOptimizedCodeMap);
   Handle<SharedFunctionInfo> shared(function->shared());
   DisallowHeapAllocation no_gc;
-  CodeAndLiterals cached = shared->SearchOptimizedCodeMap(
+  Code* code = shared->SearchOptimizedCodeMap(
       function->context()->native_context(), osr_ast_id);
-  if (cached.code != nullptr) {
+  if (code != nullptr) {
     // Caching of optimized code enabled and optimized code found.
-    if (cached.literals != nullptr) function->set_literals(cached.literals);
-    DCHECK(!cached.code->marked_for_deoptimization());
+    DCHECK(!code->marked_for_deoptimization());
     DCHECK(function->shared()->is_compiled());
-    return Handle<Code>(cached.code);
+    return Handle<Code>(code);
   }
   return MaybeHandle<Code>();
 }
@@ -546,10 +545,9 @@ void InsertCodeIntoOptimizedCodeMap(CompilationInfo* info)
{
   // Cache optimized context-specific code.
   Handle<JSFunction> function = info->closure();
   Handle<SharedFunctionInfo> shared(function->shared());
-  Handle<LiteralsArray> literals(function->literals());
   Handle<Context> native_context(function->context()->native_context());
   SharedFunctionInfo::AddToOptimizedCodeMap(shared, native_context, code,
-                                            literals, info->osr_ast_id());
+                                            info->osr_ast_id());
 }
 
 bool Renumber(ParseInfo* parse_info) {
@@ -806,10 +804,8 @@ CompilationJob::Status
FinalizeOptimizedCompilationJob(CompilationJob* job) {
     } else if (job->FinalizeJob() == CompilationJob::SUCCEEDED) {
       job->RecordOptimizedCompilationStats();
       RecordFunctionCompilation(CodeEventListener::LAZY_COMPILE_TAG, info);
-      if (shared
-              ->SearchOptimizedCodeMap(info->context()->native_context(),
-                                       info->osr_ast_id())
-              .code == nullptr) {
+      if (shared->SearchOptimizedCodeMap(info->context()->native_context(),
+                                         info->osr_ast_id()) == nullptr) {
         InsertCodeIntoOptimizedCodeMap(info);
       }
       if (FLAG_trace_opt) {
@@ -1756,19 +1752,16 @@ void Compiler::PostInstantiation(Handle<JSFunction>
function,
     function->MarkForOptimization();
   }
 
-  CodeAndLiterals cached = shared->SearchOptimizedCodeMap(
+  Code* code = shared->SearchOptimizedCodeMap(
       function->context()->native_context(), BailoutId::None());
-  if (cached.code != nullptr) {
+  if (code != nullptr) {
     // Caching of optimized code enabled and optimized code found.
-    DCHECK(!cached.code->marked_for_deoptimization());
+    DCHECK(!code->marked_for_deoptimization());
     DCHECK(function->shared()->is_compiled());
-    function->ReplaceCode(cached.code);
+    function->ReplaceCode(code);
   }
 
-  if (cached.literals != nullptr) {
-    DCHECK(shared->is_compiled());
-    function->set_literals(cached.literals);
-  } else if (shared->is_compiled()) {
+  if (shared->is_compiled()) {
     // TODO(mvstanton): pass pretenure flag to EnsureLiterals.
     JSFunction::EnsureLiterals(function);
   }

[mvstanton, 2017-01-12 08:57:40]

The CQ bit was checked by mvstanton@chromium.org

[mvstanton, 2017-01-12 08:57:40]

The patchset sent to the CQ was uploaded after l-g-t-m from
bmeurer@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org
Link to the patchset: https://codereview.chromium.org/2620753003/#ps120001
(title: "REBASE.")

[commit-bot: I haz the power, 2017-01-12 08:57:51]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-12 09:28:49]

CQ is committing da patch.

Bot data: {"patchset_id": 120001, "attempt_start_ts": 1484211460235420,
"parent_rev": "1adc70b0f9573ddd75d4094383fad1b033628da4", "commit_rev":
"31887804107bf5c103d915f5c601cfaaf1cd7cb6"}

[commit-bot: I haz the power, 2017-01-12 09:28:56]

Description was changed from

==========
[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
==========

to

==========
[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:
https://chromium.googlesource.com/v8/v8/+/31887804107bf5c103d915f5c601cfaaf1c...
==========

[commit-bot: I haz the power, 2017-01-12 09:28:57]

Committed patchset #7 (id:120001) as
https://chromium.googlesource.com/v8/v8/+/31887804107bf5c103d915f5c601cfaaf1c...

[Michael Achenbach, 2017-01-12 10:10:34]

A revert of this CL (patchset #7 id:120001) has been created in
https://codereview.chromium.org/2626863004/ by machenbach@chromium.org.

The reason for reverting is: gc stress:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gc%20stress/...

also on mac.

[mvstanton, 2017-01-12 10:52:59]

Description was changed from

==========
[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:
https://chromium.googlesource.com/v8/v8/+/31887804107bf5c103d915f5c601cfaaf1c...
==========

to

==========
[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:
https://chromium.googlesource.com/v8/v8/+/31887804107bf5c103d915f5c601cfaaf1c...
==========

[mvstanton, 2017-01-12 10:53:06]

The CQ bit was checked by mvstanton@chromium.org

[mvstanton, 2017-01-12 10:53:07]

The patchset sent to the CQ was uploaded after l-g-t-m from
bmeurer@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org
Link to the patchset: https://codereview.chromium.org/2620753003/#ps160001
(title: "GCSTRESS fix.")

[commit-bot: I haz the power, 2017-01-12 10:53:10]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-12 11:29:13]

CQ is committing da patch.

Bot data: {"patchset_id": 160001, "attempt_start_ts": 1484218386960310,
"parent_rev": "2bca05685f6d7302124a54a2b1028cbad8f2c7b3", "commit_rev":
"b8294aaa978e972978b8d82cedf63befad5d7af1"}

[commit-bot: I haz the power, 2017-01-12 11:29:17]

Description was changed from

==========
[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:
https://chromium.googlesource.com/v8/v8/+/31887804107bf5c103d915f5c601cfaaf1c...
==========

to

==========
[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:
https://chromium.googlesource.com/v8/v8/+/31887804107bf5c103d915f5c601cfaaf1c...
Review-Url: https://codereview.chromium.org/2620753003
Cr-Commit-Position: refs/heads/master@{#42264}
Committed:
https://chromium.googlesource.com/v8/v8/+/b8294aaa978e972978b8d82cedf63befad5...
==========

[commit-bot: I haz the power, 2017-01-12 11:29:19]

Committed patchset #9 (id:160001) as
https://chromium.googlesource.com/v8/v8/+/b8294aaa978e972978b8d82cedf63befad5...