Move JSObject::proto to Shape

RESOLVED DUPLICATE of bug 619271

Status

()

RESOLVED DUPLICATE of bug 619271
8 years ago
7 years ago

People

(Reporter: billm, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

This would save a pointer in JSObject.
Did you mean to EmptyShape? Moving a proto pointer to Shape does not make sense since there is a Shape for every property in an object.

/be
This move could hurt even if proto is moved EmptyShape, however. Right now to look up the prototype chain, one loops up via obj->proto. Moving proto to the empty shape at end of the shape list linked from obj->lastProp would require traversing that list first.

Also, non-natives, specifically proxies, need a proto slot.

Cc'ing Brian -- I seem to recall that he filed a bug already on consolidating type/proto/shape per-object fields.

/be
(In reply to comment #1)
> Did you mean to EmptyShape? Moving a proto pointer to Shape does not make sense
> since there is a Shape for every property in an object.
> 
> /be

The shapes are shared between different objects, though, so as long as the number of distinct shapes is much less than the number of objects created this should still help when added to Shape.

But if we do make lots of Shapes in relation to the number of JSObjects, putting the proto on EmptyShape would also work; the length of the lastProp chains is k-limited for non-dictionaries (would need to do something special for dictionary objects). With type inference, few prototype lookups will be needed anyways so a bigger O(1) cost might not be too bad.

The type inference branch already consolidates object->type and object->proto, by storing the prototype on the type itself (shape determines type, type determines prototype).  It also moves emptyShapes to the type, but adds a 'union { newType; initializedLength; }' for no net change in the size of JSObject.
Forgot: this shouldn't conflict with the changes being made in the jaegermonkey branch, since JSObject::type could also move to Shape/EmptyShape.
(In reply to comment #3)
> The type inference branch already consolidates object->type and object->proto,
> by storing the prototype on the type itself (shape determines type, type
> determines prototype).  It also moves emptyShapes to the type, but adds a
> 'union { newType; initializedLength; }' for no net change in the size of
> JSObject.

Cool, that was what I half-remembered. Hoping we can see some incremental patch landing -- possible?

In any case a coordinated plan that estimates the space tradeoffs would be good. Also, Shape itself should shrink. I will file a bug on that.

/be
The ObjShrink work moved proto to the type object, so I don't think there's anything to be done here.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 619271
You need to log in before you can comment on or make changes to this bug.