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)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla50
Tracking Status
firefox50 --- fixed

People

(Reporter: Waldo, Assigned: Waldo)

References

Details

Attachments

(1 file)

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.
Attached patch PatchSplinter Review
Attachment #8768168 - Flags: review?(efaustbmo)
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
(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.
https://hg.mozilla.org/mozilla-central/rev/5fbfd52e0267
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
Depends on: 1340482
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: