Don't clear the string stub at gc time in KeyedLoadIC.
authormvstanton@chromium.org <mvstanton@chromium.org>
Wed, 1 Oct 2014 11:09:06 +0000 (11:09 +0000)
committermvstanton@chromium.org <mvstanton@chromium.org>
Wed, 1 Oct 2014 11:09:06 +0000 (11:09 +0000)
Clearing this stub doesn't actually make sense, as it neither leaks
memory, nor prevents finding a new optimum stable state. As
long as strings receivers are observed, this is the best stub.
The moment we see a non-string receiver we'll go polymorphic
or generic depending on the case.

R=yangguo@chromium.org

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24360 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

src/ic/ic.cc

index cb897c7..52e3496 100644 (file)
@@ -511,10 +511,16 @@ void IC::Clear(Isolate* isolate, Address address,
 void KeyedLoadIC::Clear(Isolate* isolate, Address address, Code* target,
                         ConstantPoolArray* constant_pool) {
   if (IsCleared(target)) return;
-  // Make sure to also clear the map used in inline fast cases.  If we
-  // do not clear these maps, cached code can keep objects alive
-  // through the embedded maps.
-  SetTargetAtAddress(address, *pre_monomorphic_stub(isolate), constant_pool);
+
+  // If the target is the string_stub, then don't clear it. It is the
+  // perfect stub if we continue to see strings. Holding this
+  // state is not preventing learning new information.
+  if (target != *isolate->builtins()->KeyedLoadIC_String()) {
+    // Make sure to also clear the map used in inline fast cases.  If we
+    // do not clear these maps, cached code can keep objects alive
+    // through the embedded maps.
+    SetTargetAtAddress(address, *pre_monomorphic_stub(isolate), constant_pool);
+  }
 }