- Start using the collected store buffer entries to find

vm/store_buffer.cc

Index: vm/store_buffer.cc
===================================================================
--- vm/store_buffer.cc	(revision 9751)
+++ vm/store_buffer.cc	(working copy)
@@ -44,7 +44,7 @@
   DedupSet* current = dedup_sets_;
   dedup_sets_ = NULL;
   while (current != NULL) {
-    DedupSet* next = current->next_;
+    DedupSet* next = current->next();
     delete current;
     current = next;
   }
@@ -53,15 +53,15 @@
 
 void StoreBuffer::AddPointer(uword address) {
   ASSERT(dedup_sets_ != NULL);
-  if (!dedup_sets_->set_->Add(address)) {
-    // TODO(iposva): Limit growth of deduplication sets until the rest of the
-    // mechanism is hooked up.
-    delete dedup_sets_;
-    dedup_sets_ = NULL;
-
-    DedupSet* fresh_element = new DedupSet();
-    fresh_element->next_ = dedup_sets_;
-    dedup_sets_ = fresh_element;
+  if (!dedup_sets_->set()->Add(address)) {
+    // Add a new DedupSet. Schedule an interrupt if we have run over the max
+    // number of DedupSets.
+    dedup_sets_ = new DedupSet(dedup_sets_);
+    count_++;
+    // TODO(iposva): Fix magic number.
+    if (count_ > 100) {
+      Isolate::Current()->ScheduleInterrupts(Isolate::kStoreBufferInterrupt);
+    }

[siva, 2012/07/19 17:36:06]

If we overflow again before the interrupt actually happens we will end up
scheduling another interrupt causing back to back GCs. Is this scenario
possible?

[Ivan Posva, 2012/07/20 15:37:46]

You can schedule an interrupt as many times as you want. The handler will be
only called once when the interrupt is pending. Once the interrupt is cleared
and in process of being handled you can schedule new interrupts. As far as I can
see a back-to-back Scavenge can happen only if the scavenging itself caused an
overflow. I do have a plan for avoiding this, but it is not part of this CL.

   }
 }