On 2015/02/04 11:08:10, ulan wrote:
https://codereview.chromium.org/893073006/diff/1/src/ia32/lithium-codegen-ia32.cc
File src/ia32/lithium-codegen-ia32.cc (right):
https://codereview.chromium.org/893073006/diff/1/src/ia32/lithium-codegen-ia32.cc#newcode2995
src/ia32/lithium-codegen-ia32.cc:2995: __ mov(result, FieldOperand(object,
HeapObject::kMapOffset));
On 2015/02/04 10:49:42, Erik Corry wrote:
> On 2015/02/04 09:35:04, ulan wrote:
> > __ mov(FieldOperand(object, HeapObject::kMapOffset), result);
>
> This is intended to be a store, not a load.
Yep. The destination of the mov is the first argument :)
Doh!
https://code.google.com/p/chromium/codesearch#chromium/src/v8/src/ia32/assembler-ia32.h&l=638
https://codereview.chromium.org/893073006/diff/1/src/ic/ia32/ic-compiler-ia32.cc
File src/ic/ia32/ic-compiler-ia32.cc (right):
https://codereview.chromium.org/893073006/diff/1/src/ic/ia32/ic-compiler-ia32.cc#newcode117
src/ic/ia32/ic-compiler-ia32.cc:117: Handle<WeakCell> cell =
Map::WeakCellForMap(transitioned_maps->at(i));
On 2015/02/04 10:49:42, Erik Corry wrote:
> On 2015/02/04 09:35:04, ulan wrote:
> > On 2015/02/03 17:42:53, Erik Corry http://Chromium.org wrote:
> > > 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?
> >
> > 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.
>
> 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?
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.
The back pointers are sometimes cleared, though.
I think ideally all the transition pointers (forward and back) would be
weak,
and using them like this would mark them used. On every GC they would be
zapped
(or aged and conditionally zapped) if they were unused. I'm not even sure
we
need the back pointers in that case. I think they are there to stop
intermediate maps that are part of heavily used transition chains from being
collected, but having use-detection would achieve that more directly, and
would
track what we really need to know: "Was the transition chain used?" rather
than
"Is there still a long lived object that maybe used the transition a long
time
ago?".
The receiver map will not necessarily keep anything alive since that object
could be long dead by the next full GC.
https://codereview.chromium.org/893073006/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
