Fix for HeapSnapshotAddressReuse test case.

Fix for HeapSnapshotAddressReuse test case.


BUG=V8:2189
TEST=HeapSnapshotAddressReuse

Committed: https://code.google.com/p/v8/source/detail?r=13721

[yurys, 2013-02-21 15:26:43]

https://codereview.chromium.org/12320039/diff/1/src/heap-snapshot-generator.cc
File src/heap-snapshot-generator.cc (right):

https://codereview.chromium.org/12320039/diff/1/src/heap-snapshot-generator.c...
src/heap-snapshot-generator.cc:402: void HeapObjectsMap::MoveObject(Address
from, Address to) {
Is it possible that an object is allocated (not moved) directly at an address of
already tracked object?

https://codereview.chromium.org/12320039/diff/1/src/heap-snapshot-generator.c...
src/heap-snapshot-generator.cc:408: // We don't know the object that may occupy
the place of a known object.
I'd rephrase like this:

"It may occur that some untracked object moves to an address X and there is a
tracked object at that address. In this case we should remove the entry as we
know that the object has died."

https://codereview.chromium.org/12320039/diff/1/src/heap-snapshot-generator.c...
src/heap-snapshot-generator.cc:409: // In that case we need to remove the entry
for this died known object.
died -> dead

https://codereview.chromium.org/12320039/diff/1/src/heap-snapshot-generator.c...
src/heap-snapshot-generator.cc:419: // We found the entry with to address for an
old object.
the entry -> existing entry

https://codereview.chromium.org/12320039/diff/1/src/heap-snapshot-generator.c...
src/heap-snapshot-generator.cc:430: to_entry->value =
reinterpret_cast<void*>(from_entry_info_index);
to_entry->value = from_value; ?

[loislo, 2013-02-21 20:35:37]

On 2013/02/21 15:26:43, Yury Semikhatsky wrote:
> https://codereview.chromium.org/12320039/diff/1/src/heap-snapshot-generator.cc
> File src/heap-snapshot-generator.cc (right):
> 
>
https://codereview.chromium.org/12320039/diff/1/src/heap-snapshot-generator.c...
> src/heap-snapshot-generator.cc:402: void HeapObjectsMap::MoveObject(Address
> from, Address to) {
> Is it possible that an object is allocated (not moved) directly at an address
of
> already tracked object?

As far as I know it is possible but it is another case.

> 
>
https://codereview.chromium.org/12320039/diff/1/src/heap-snapshot-generator.c...
> src/heap-snapshot-generator.cc:408: // We don't know the object that may
occupy
> the place of a known object.
> I'd rephrase like this:
> 
> "It may occur that some untracked object moves to an address X and there is a
> tracked object at that address. In this case we should remove the entry as we
> know that the object has died."

done 

>
https://codereview.chromium.org/12320039/diff/1/src/heap-snapshot-generator.c...
> src/heap-snapshot-generator.cc:419: // We found the entry with to address for
an
> old object.
> the entry -> existing entry

done

> 
>
https://codereview.chromium.org/12320039/diff/1/src/heap-snapshot-generator.c...
> src/heap-snapshot-generator.cc:430: to_entry->value =
> reinterpret_cast<void*>(from_entry_info_index);
> to_entry->value = from_value; ?

done

[yurys, 2013-02-22 06:33:19]

lgtm

[Michael Starzinger, 2013-02-25 15:11:48]

LGTM as far as I can tell.

https://codereview.chromium.org/12320039/diff/4001/src/heap-snapshot-generato...
File src/heap-snapshot-generator.cc (right):

https://codereview.chromium.org/12320039/diff/4001/src/heap-snapshot-generato...
src/heap-snapshot-generator.cc:414:
static_cast<int>(reinterpret_cast<intptr_t>(to_value));
Indentation is off, also at two other occurrences below.

[loislo, 2013-02-25 16:10:04]

Committed patchset #4 manually as r13721 (presubmit successful).