LGTM with one comment to address and one suggestion.
https://codereview.chromium.org/203523009/diff/20001/src/objects.cc
File src/objects.cc (right):
https://codereview.chromium.org/203523009/diff/20001/src/objects.cc#newcode2281
src/objects.cc:2281: static void RightTrimFixedArray(Heap* heap,
FixedArray* elms, int to_trim) {
As discussed offline: There also is access to the mark-bits in
LeftTrimFixedArray. The access is well hidden in Heap::TransferMark(),
where we also need to do an early return if incremental marking is not
running.
https://codereview.chromium.org/203523009/diff/20001/src/objects.cc#newcode2307
src/objects.cc:2307: Marking::IsBlack(Marking::MarkBitFrom(elms))) {
As discussed offline: I am not sure distinguishing between friends of
"Marking" or not will help, because it mainly depends on the call-path
leading there, not so much the call-site
Another proposal would be to factor our this general logic for adjusting
live bytes into a Heap::AdjustLiveBytes() helper that would take care of
checking the proper pre-conditions. The RightTrimMode would probably
need to be renamed to something like LiveBytesAdjustmentMode.
https://codereview.chromium.org/203523009/
--
--
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.
