Age inline caches after context disposal.

src/mark-compact.cc

Index: src/mark-compact.cc
diff --git a/src/mark-compact.cc b/src/mark-compact.cc
index b956e73e10e3a285b4dc6bb15b8926c50f5b11db..1d773188994873085592937d2739d9ffcb8dfef9 100644
--- a/src/mark-compact.cc
+++ b/src/mark-compact.cc
@@ -1049,7 +1049,9 @@ class StaticMarkingVisitor : public StaticVisitorBase {
     Code* target = Code::GetCodeFromTargetAddress(rinfo->target_address());
     if (FLAG_cleanup_code_caches_at_gc && target->is_inline_cache_stub()
         && (target->ic_state() == MEGAMORPHIC ||
-            heap->mark_compact_collector()->flush_monomorphic_ics_)) {
+            heap->mark_compact_collector()->flush_monomorphic_ics_ ||
+            target->context_disposed_count() !=
+            heap->global_context_disposed_count())) {
       IC::Clear(rinfo->pc());

[Vyacheslav Egorov (Chromium), 2012/03/22 14:47:05]

I would expect we reset counter to be equal to
heap_->global_context_disposed_count() otherwise we would flush again on the
next GC even if the context was not disposed.

surely reset should not happen in the place but at the place which calls
visitor.

[ulan, 2012/03/23 10:47:13]

As discussed offline, this should work because we flush stub caches on GC

       target = Code::GetCodeFromTargetAddress(rinfo->target_address());
     }
@@ -1405,6 +1407,12 @@ class StaticMarkingVisitor : public StaticVisitorBase {
 
     if (shared->IsInobjectSlackTrackingInProgress()) shared->DetachInitialMap();
 
+    if (shared->context_disposed_count() !=
+        heap->global_context_disposed_count()) {
+      shared->set_context_disposed_count(heap->global_context_disposed_count());

[Vyacheslav Egorov (Chromium), 2012/03/22 14:47:05]

I suppose this piece of code is here to prevent optimizer from optimizing to
early. 

There are heuristics that try to decide whether function should be optimized
based on the amount of initialized ICs.

Why do we need to reset opt_count separately? I would expect initialized ICs
heuristic to cover it.

Also we were discussing with Jakob if we should move opt_count to the code
object itself. This would allow to easily adjust it when we clear ICs instead of
doing special (spooky) handling of shared function info.

[ulan, 2012/03/23 10:47:13]

This is to prevent us from marking a function as non-optimizable after N page
reloads when the opt_count reaches kMaxOptCount.

I will submit this part as a separate CL.

On 2012/03/22 14:47:05, Vyacheslav Egorov wrote:

+      shared->set_opt_count(0);
+    }
+
     if (!known_flush_code_candidate) {
       known_flush_code_candidate = IsFlushable(heap, shared);
       if (known_flush_code_candidate) {