A few more comments.

http://codereview.chromium.org/3329019/diff/1/10
File src/objects.cc (right):

http://codereview.chromium.org/3329019/diff/1/10#newcode5434
src/objects.cc:5434:
set_inobject_slack_estimation(unused_inobject_properties);
If unused_inobject_properties is 0, then this half-cancels the tracking
(IsInobjectSlackTrackingInProgress() becomes false). Is this a problem?
If not, it's still too subtle and requires a comment.

http://codereview.chromium.org/3329019/diff/1/10#newcode5454
src/objects.cc:5454: // Make the counter runs out the next time.
Why do we have to postpone it? Can we call Complete...Tracking() here?

http://codereview.chromium.org/3329019/diff/1/11
File src/objects.h (right):

http://codereview.chromium.org/3329019/diff/1/11#newcode3246
src/objects.h:3246: // The size limit for a map transition tree that can
be safely processed
If we have a "class" with 51 functions, does this limit mean we'll
always be too generous when allocating the instances? If yes, this could
be bad for memory usage. I understand that this limit should not affect
the normal usage of putting the functions on the prototype, but some OO
frameworks put the functions on the instance.

Please have a look at http://codereview.chromium.org/3385002 where I
attempt to do a stackless traversal of the map tree.

http://codereview.chromium.org/3329019/diff/1/11#newcode3248
src/objects.h:3248: static const int kMaxShrinkableTreeSize = 50;
kMaxShrinkable*Transition*TreeSize?

http://codereview.chromium.org/3329019/diff/1/11#newcode3457
src/objects.h:3457: // Inobject slack tracking:
This comment needs to also explain how different contexts sharing a
function are affected by tracking.

http://codereview.chromium.org/3329019/diff/1/11#newcode3463
src/objects.h:3463: // To reclaims unused inobject space we:
reclaims -> reclaim.

http://codereview.chromium.org/3329019/diff/1/11#newcode3488
src/objects.h:3488: inline bool IsInobjectSlackTrackingInProgress();
Please describe the full state machine here.

http://codereview.chromium.org/3329019/show

--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev

Reply via email to