The comment in the objects-visiting-inl.h file should make it clear that
this is
complexity that is barely executed (as our test suite apparently never
triggers
two bugs in this change). This again begs the question whether all of this
complexity is actually necessary.
A third bug with this short-circuiting is that it could potentially
introduce a
pointer from code-space to new-space, as one half of the cons-string could
very
well be in new-space whereas the cons-string itself has been in old-space.
As discussed offline yesterday: I would very much prefer to just flatten the
string at compile-time since this only happens for constant folding of
string
literals at compile-time. So unless you can show me cases where this
complexity
is actually necessary, I'll stick to my position that we shouldn't
short-circuit
embedded strings at all.
https://codereview.chromium.org/17418003/diff/9001/src/objects-visiting-inl.h
File src/objects-visiting-inl.h (right):
https://codereview.chromium.org/17418003/diff/9001/src/objects-visiting-inl.h#newcode240
src/objects-visiting-inl.h:240: Object** target_address =
rinfo->target_object_address();
This change is missing the slot recording for the reloc slot in the
code. Frankly it surprises me that this would pass the test suite.
Also I am not sure passing a non-heap slot to the StaticVisitor here
will work, because if the target happens to be in an evacuation
candidate this stack(!) slot will be recorded in the slots buffer.
https://codereview.chromium.org/17418003/
--
--
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/groups/opt_out.
