Clear optimized code cache in shared function info when code gets deoptimized

Clear optimized code cache in shared function info when code gets deoptimized.

This adds a pointer to the shared function info into deoptimization data of an optimized code. Whenever the code is deoptimized, it clears the cache in the shared function info.

This fixes the problem when the optimized function dies in new space GC before the code is deoptimized due to code dependency and before the optimized code cache is cleared in old space GC (see mjsunit/regress/regress-343609.js).

This partially reverts r19603 because we need to be able to evict specific code from the optimized code cache.

BUG=343609
LOG=Y
TEST=mjsunit/regress/regress-343609.js
R=yangguo@chromium.org

Committed: https://code.google.com/p/v8/source/detail?r=19635

[ulan, 2014-03-01 13:59:43]

PTAL

https://codereview.chromium.org/184923002/diff/20001/src/compiler.cc
File src/compiler.cc (right):

https://codereview.chromium.org/184923002/diff/20001/src/compiler.cc#newcode1073
src/compiler.cc:1073: return
Handle<Code>(shared->GetCodeFromOptimizedCodeMap(index));
Revert change from r19603

https://codereview.chromium.org/184923002/diff/20001/src/factory.cc
File src/factory.cc (right):

https://codereview.chromium.org/184923002/diff/20001/src/factory.cc#newcode970
src/factory.cc:970:
result->ReplaceCode(function_info->GetCodeFromOptimizedCodeMap(index));
Revert change from r19603

https://codereview.chromium.org/184923002/diff/20001/src/objects-inl.h
File src/objects-inl.h (left):

https://codereview.chromium.org/184923002/diff/20001/src/objects-inl.h#oldcod...
src/objects-inl.h:5440:
shared()->EvictFromOptimizedCodeMap(context()->native_context(),
Partial revert of r19603, we don't need to keep code cache and optimized
function list in sync anymore.

https://codereview.chromium.org/184923002/diff/20001/src/objects.cc
File src/objects.cc (right):

https://codereview.chromium.org/184923002/diff/20001/src/objects.cc#newcode9634
src/objects.cc:9634: void SharedFunctionInfo::EvictFromOptimizedCodeMap(Code*
optimized_code,
Revert change from r19603

https://codereview.chromium.org/184923002/diff/20001/src/objects.h
File src/objects.h (right):

https://codereview.chromium.org/184923002/diff/20001/src/objects.h#newcode6667
src/objects.h:6667: // Removed a specific optimized code object from the
optimized code map.
Revert change from r19603

[Yang, 2014-03-03 07:50:14]

LGTM. We may want to discuss whether it makes sense to leave other optimized
code objects in the optimized code map after one of them deopted.

https://codereview.chromium.org/184923002/diff/20002/src/arm/deoptimizer-arm.cc
File src/arm/deoptimizer-arm.cc (right):

https://codereview.chromium.org/184923002/diff/20002/src/arm/deoptimizer-arm....
src/arm/deoptimizer-arm.cc:74: // deoptimization entry.
Comment is now a bit confusing.

[ulan, 2014-03-03 09:20:33]

https://codereview.chromium.org/184923002/diff/20002/src/arm/deoptimizer-arm.cc
File src/arm/deoptimizer-arm.cc (right):

https://codereview.chromium.org/184923002/diff/20002/src/arm/deoptimizer-arm....
src/arm/deoptimizer-arm.cc:74: // deoptimization entry.
On 2014/03/03 07:50:14, Yang wrote:
> Comment is now a bit confusing.
Moved it down.

[ulan, 2014-03-03 11:11:55]

Committed patchset #5 manually as r19635 (tree was closed).

[titzer, 2014-03-03 12:02:44]

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

https://codereview.chromium.org/184923002/diff/80001/src/objects.cc#newcode9641
src/objects.cc:9641: for (i = kEntriesStart; i < code_map->length(); i +=
kEntryLength) {
This code is relying on the code appearing only once in this optimized code map,
which is an invariant that should hold, but based on my investigation, looks
quite fragile.

Can we put an extra level of checking in this loop?

I.e. either go through the entire map and remove _all_ occurrences, or assert
there is only one.

I would prefer the former, since we have to loop over the entire array anyway,
even if we found it.

https://codereview.chromium.org/184923002/diff/80001/src/objects.cc#newcode9643
src/objects.cc:9643: if (Code::cast(code_map->get(i + 1)) == optimized_code) {
Please use kCachedCodeOffset here.

[Yang, 2014-03-03 12:04:34]

On 2014/03/03 12:02:44, titzer wrote:
> https://codereview.chromium.org/184923002/diff/80001/src/objects.cc
> File src/objects.cc (right):
> 
>
https://codereview.chromium.org/184923002/diff/80001/src/objects.cc#newcode9641
> src/objects.cc:9641: for (i = kEntriesStart; i < code_map->length(); i +=
> kEntryLength) {
> This code is relying on the code appearing only once in this optimized code
map,
> which is an invariant that should hold, but based on my investigation, looks
> quite fragile.
> 
> Can we put an extra level of checking in this loop?
> 
> I.e. either go through the entire map and remove _all_ occurrences, or assert
> there is only one.
> 
> I would prefer the former, since we have to loop over the entire array anyway,
> even if we found it.
> 
>
https://codereview.chromium.org/184923002/diff/80001/src/objects.cc#newcode9643
> src/objects.cc:9643: if (Code::cast(code_map->get(i + 1)) == optimized_code) {
> Please use kCachedCodeOffset here.

That's actually a good point. I agree.

[ulan, 2014-03-03 12:24:54]

On 2014/03/03 12:04:34, Yang wrote:
> On 2014/03/03 12:02:44, titzer wrote:
> > https://codereview.chromium.org/184923002/diff/80001/src/objects.cc
> > File src/objects.cc (right):
> > 
> >
>
https://codereview.chromium.org/184923002/diff/80001/src/objects.cc#newcode9641
> > src/objects.cc:9641: for (i = kEntriesStart; i < code_map->length(); i +=
> > kEntryLength) {
> > This code is relying on the code appearing only once in this optimized code
> map,
> > which is an invariant that should hold, but based on my investigation, looks
> > quite fragile.
> > 
> > Can we put an extra level of checking in this loop?
> > 
> > I.e. either go through the entire map and remove _all_ occurrences, or
assert
> > there is only one.
> > 
> > I would prefer the former, since we have to loop over the entire array
anyway,
> > even if we found it.
> > 
> >
>
https://codereview.chromium.org/184923002/diff/80001/src/objects.cc#newcode9643
> > src/objects.cc:9643: if (Code::cast(code_map->get(i + 1)) == optimized_code)
{
> > Please use kCachedCodeOffset here.
> 
> That's actually a good point. I agree.

Uploaded a CL that addresses it: https://codereview.chromium.org/181493004