Closed
Bug 1284634
Opened 8 years ago
Closed 8 years ago
Introduce ShapedObject as a base class containing a shape field, for subclassing by NativeObject and ProxyObject
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
FIXED
mozilla50
Tracking | Status | |
---|---|---|
firefox50 | --- | fixed |
People
(Reporter: Waldo, Assigned: Waldo)
References
Details
Attachments
(1 file)
41.48 KB,
patch
|
efaust
:
review+
|
Details | Diff | Splinter Review |
In the process of investigating an unrelated bug, I discovered we do pretty scary things around shapes and object subclassing. Let's introduce ShapedObject as a single JSObject subclass to hold shape-related information, for all object subclasses that use a shape field.
Assignee | ||
Comment 1•8 years ago
|
||
Attachment #8768168 -
Flags: review?(efaustbmo)
Comment 2•8 years ago
|
||
Comment on attachment 8768168 [details] [diff] [review] Patch Review of attachment 8768168 [details] [diff] [review]: ----------------------------------------------------------------- Seems good to me with comments addressed. ::: js/src/builtin/TypedObject.h @@ +489,5 @@ > static const Class class_; > }; > > /* Base type for transparent and opaque typed objects. */ > +class TypedObject : public ShapedObject We're changing the accessibility of TypedObject::shape_ here. Does it matter? Seems a little weird to change the shape of a TypedObject. ::: js/src/jsobjinlines.h @@ +51,5 @@ > JSObject::maybeShape() const > { > if (is<js::UnboxedPlainObject>() || is<js::UnboxedArrayObject>()) > return nullptr; > + return *reinterpret_cast<js::Shape**>(uintptr_t(this) + js::ShapedObject::offsetOfShape()); This is /so/ scary. I guess the point here is that it's supposed to look as scary as it is, and static_cast might lull you into a false sense of security? What about: if (!is<js::ShapedObject>()) return nullptr; return as<js::ShapedObject>().shape_; (or with some accessor) ::: js/src/vm/ShapedObject.h @@ +27,5 @@ > + // Set the shape of an object. This pointer is valid for native objects and > + // some non-native objects. After creating an object, the objects for which > + // the shape pointer is invalid need to overwrite this pointer before a GC > + // can occur. > + void setInitialShapeMaybeNonNative(Shape* shape) { I still object to this MaybeNonNative stuff. Is the argument now that it reflects that proxies are also ShapedObjects?
Attachment #8768168 -
Flags: review?(efaustbmo) → review+
Pushed by jwalden@mit.edu: https://hg.mozilla.org/integration/mozilla-inbound/rev/5fbfd52e0267 Introduce ShapedObject as a base class containing a shape field, for subclassing by NativeObject and ProxyObject. r=efaust
Assignee | ||
Comment 4•8 years ago
|
||
(In reply to Eric Faust [:efaust] from comment #2) > We're changing the accessibility of TypedObject::shape_ here. Does it > matter? Seems a little weird to change the shape of a TypedObject. Hm, actually this can just be protected without any trouble. (Private would be better, but then you run into the Proxy_trace thing I mentioned on IRC.) Changed for parity with the prior state. > > + return *reinterpret_cast<js::Shape**>(uintptr_t(this) + js::ShapedObject::offsetOfShape()); > > This is /so/ scary. I guess the point here is that it's supposed to look as > scary as it is, and static_cast might lull you into a false sense of > security? > > What about: I think it was scary before because there was no common class to hold shape_, so this was the only way to do it. With ShapedObject, yeah, makes sense to do this sensibly. > I still object to this MaybeNonNative stuff. Is the argument now that it > reflects that proxies are also ShapedObjects? Eh, it was just try not to rock the boat too much. But I guess if every user has to be touched anyway, might as well modify this. I went with initShape/setShape.
Comment 5•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/5fbfd52e0267
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
status-firefox50:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
You need to log in
before you can comment on or make changes to this bug.
Description
•