Add map-based read barrier to WeakCell

src/ic/ia32/ic-compiler-ia32.cc

Index: src/ic/ia32/ic-compiler-ia32.cc
diff --git a/src/ic/ia32/ic-compiler-ia32.cc b/src/ic/ia32/ic-compiler-ia32.cc
index f43b641134d873e5af26eafedcaee4d9a93170ce..a553c53aaba1be20dcf096d9765dd1ffede9af5a 100644
--- a/src/ic/ia32/ic-compiler-ia32.cc
+++ b/src/ic/ia32/ic-compiler-ia32.cc
@@ -115,7 +115,7 @@ Handle<Code> PropertyICCompiler::CompileKeyedStorePolymorphic(
       Label next_map;
       __ j(not_equal, &next_map, Label::kNear);
       Handle<WeakCell> cell = Map::WeakCellForMap(transitioned_maps->at(i));

[Erik Corry Chromium.org, 2015/02/03 17:42:53]

I think perhaps here we should trigger the read barrier on the first cell (yeah
there are two variables called cell in this function!) to show that it is in use
and should not be cleared on GC. What do you think?

[ulan, 2015/02/04 09:35:04]

Do you mean read barrier on receiver_map? I think we don't need it. If the
compare succeeds than we already have the receiver map in register, so it must
be alive. If the compare fails, then we have no information and we didn't "use"
the map.

[Erik Corry, 2015/02/04 10:49:42]

I agree we don't need it for correctness.  The question is whether it could be
useful for tracking whether the map was recently used, so that we can extend its
life in GC even if there are no live objects using it at the next GC.  But I'm
not exactly sure what's going on here: Does this count as a recent use that
should prevent weak map clearing at the next GC?

[ulan, 2015/02/04 11:08:10]

The transitioned_map[i] has a back pointer to the current map (which is equal to
the receiver_map[i] since the map check succeeded). So I think the read barrier
for transitioned_map[i] would keep also receiver_map[i] alive.

-      __ LoadWeakValue(transition_map(), cell, &miss);
+      __ LoadWeakValue(transition_map(), cell, scratch2(), &miss);
       __ jmp(handler_stubs->at(i), RelocInfo::CODE_TARGET);
       __ bind(&next_map);
     }