Addressed comments.

https://codereview.chromium.org/957273002/diff/130001/src/heap/mark-compact.cc
File src/heap/mark-compact.cc (right):

https://codereview.chromium.org/957273002/diff/130001/src/heap/mark-compact.cc#newcode4292
src/heap/mark-compact.cc:4292: void SlotsBuffer::RemoveSlot(SlotsBuffer*
buffer, ObjectSlot slot_to_remove) {
On 2015/03/03 09:48:53, Hannes Payer wrote:
I think it would be more efficient to just clear the slot instead of
moving
everything to the left.

Done.

https://codereview.chromium.org/957273002/diff/130001/src/heap/spaces.h
File src/heap/spaces.h (right):

https://codereview.chromium.org/957273002/diff/130001/src/heap/spaces.h#newcode389
src/heap/spaces.h:389: // FLAG_stress_compaction and
FLAG_manual_evacuation_candidates_selection
On 2015/03/03 09:48:53, Hannes Payer wrote:
I don't think we need the FLAG_stress_compaction dependency.

I would prefer to leave this dependency in order to reduce the number of
unnecessary checks in
MarkCompactCollector::CollectEvacuationCandidates() for production code.

https://codereview.chromium.org/957273002/diff/130001/src/heap/store-buffer.cc
File src/heap/store-buffer.cc (right):

https://codereview.chromium.org/957273002/diff/130001/src/heap/store-buffer.cc#newcode250
src/heap/store-buffer.cc:250: // Returns number of slots stored in the
slots buffer.
On 2015/03/03 09:48:53, Hannes Payer wrote:
store buffer

Done.

https://codereview.chromium.org/957273002/diff/130001/src/heap/store-buffer.cc#newcode251
src/heap/store-buffer.cc:251: int StoreBuffer::SizeForTesting() {
On 2015/03/03 09:48:53, Hannes Payer wrote:
Why is it called SizeForTesting? Why don't call it
NumberOfRecordedSlots or
something like that.

Actually it doesn't make sense. Removed.

https://codereview.chromium.org/957273002/diff/130001/src/heap/store-buffer.cc#newcode259
src/heap/store-buffer.cc:259: void StoreBuffer::RemoveSlots(Address
start_address, Address end_address) {
On 2015/03/03 09:48:53, Hannes Payer wrote:
How often do you think is this function called. If it is called *many*
times, we
will copy many times the store buffer entries. Wouldn't it be more
efficient to
invalidate the store buffer entries?

Good point.

https://codereview.chromium.org/957273002/diff/130001/src/heap/store-buffer.h
File src/heap/store-buffer.h (right):

https://codereview.chromium.org/957273002/diff/130001/src/heap/store-buffer.h#newcode109
src/heap/store-buffer.h:109: // Returns number of slots stored in the
slots buffer.
On 2015/03/03 09:48:53, Hannes Payer wrote:
store buffer

Done.

https://codereview.chromium.org/957273002/diff/130001/src/objects.cc
File src/objects.cc (right):

https://codereview.chromium.org/957273002/diff/130001/src/objects.cc#newcode2120
src/objects.cc:2120: // both StoreBuffer or respective SlotsBuffer.
On 2015/03/03 09:48:53, Hannes Payer wrote:
"or respective" => "and"

Done.

https://codereview.chromium.org/957273002/diff/130001/src/objects.cc#newcode2126
src/objects.cc:2126: Address end_address = obj_address +
old_map->instance_size();
On 2015/03/03 09:48:53, Hannes Payer wrote:
Why are you removing all the pointers?

Because in the next loop all the values will be written again and
correct slots will be added to respective store/slots buffer.

https://codereview.chromium.org/957273002/

--
--
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.

Reply via email to