Kannan tells me we can get this information pretty easily via the JIT's type objects -> ... something ... -> JSScript of constructor -> displayAtom. This would be awesome, and it would be cool to use this as a potential grouping for JSObjects in takeCensus.

So I tried to figure out how to get this info given any old JSObject, and I couldn't find any way to get the JSScript it was new'd in (assuming it was created with new). I used the implementation of |obj instanceof Func| as it seems like it would be doing similar things. Unfortunately, it just grabs Func.prototype and then walks obj's prototype chain to see if it finds Func.prototype. Kannan, is this information no longer easily accessible?

(s/used the implementation/looked at the implementation/)

It's a bit roundabout. From the object, you can get the ObjectGroup. Now, if the object was constructed using 'new F()' for some scripted function F, then the ObjectGroup will contain an Addendum_NewScript, referring to a TypeNewScript. The TypeNewScript contains a reference to the JSFunction that is the constructor. You can get the JSScript from that.

Hm so I think `JSObject::makeLazyGroup` can GC (mrgiggles is seriously out of date), so if the object's group is lazy, it isn't safe for ubi::Node to get the object's constructor name (ubi::Nodes are invalidated if their referent moves). When are groups lazy? Is it only for lazy functions? It looks like `ObjectGroupCompartment::makeGroup` can probably GC, too. No bueno. What would the ramifications be if we only yielded constructor names for objects without a lazy group?

https://dxr.mozilla.org/mozilla-central/source/js/src/vm/ObjectGroup.h#158-161 > * Object groups which represent at most one JS object are constructed lazily. > * These include groups for native functions, standard classes, scripted > * functions defined at the top level of global/eval scripts, and in some > * other cases. Hm. Sounds like that is a whole lot of different things that get lazy groups, but also specifically doesn't include the set of objects that are likely to take up most of your heap or be most of your allocations.

(In reply to Nick Fitzgerald [:fitzgen] from comment #6) > Created attachment 8595111 [details] [diff] [review] > Part 1: Add JSObject::constructorDisplayAtom WIP patch that adds `JSObject::constructorDisplayAtom` and doesn't address the GC concerns.

(In reply to Nick Fitzgerald [:fitzgen] from comment #4) > Hm so I think `JSObject::makeLazyGroup` can GC (mrgiggles is seriously out > of date), so if the object's group is lazy, it isn't safe for ubi::Node to > get the object's constructor name (ubi::Nodes are invalidated if their > referent moves). > > When are groups lazy? Is it only for lazy functions? It looks like > `ObjectGroupCompartment::makeGroup` can probably GC, too. No bueno. > > What would the ramifications be if we only yielded constructor names for > objects without a lazy group? (In reply to Nick Fitzgerald [:fitzgen] from comment #5) > https://dxr.mozilla.org/mozilla-central/source/js/src/vm/ObjectGroup.h#158- > 161 > > > * Object groups which represent at most one JS object are constructed lazily. > > * These include groups for native functions, standard classes, scripted > > * functions defined at the top level of global/eval scripts, and in some > > * other cases. > > Hm. Sounds like that is a whole lot of different things that get lazy > groups, but also specifically doesn't include the set of objects that are > likely to take up most of your heap or be most of your allocations. Talked to Shu today and he confirmed that (a) lazy objects groups for only a single JS object are not as important as non-lazy object groups for many objects (intuitively, the latter are what you will see a lot more of in the heap), and (b) some information is better than none in this case. Note that this no-GC stuff only applies to JS::ubi::Node, not the allocations log.

Try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=10105bd04460

Comment on attachment 8595663 [details] [diff] [review] Part 1: Add JSObject::constructorDisplayAtom Review of attachment 8595663 [details] [diff] [review]: ----------------------------------------------------------------- ::: js/src/jsobj.cpp @@ +4102,5 @@ > + > +static JSAtom* > +displayAtomFromObjectGroup(ObjectGroup& group) > +{ > + auto script = group.newScript(); Don't use |auto| here. It's better to have explicit type declarations that tell the reader clearly what type is being retrieved. @@ +4112,5 @@ > + > +bool > +JSObject::constructorDisplayAtom(JSContext* cx, js::MutableHandleAtom name) > +{ > + auto *g = getGroup(cx); Same as above.

New try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=7ac1356adad8

Didn't like AutoCompartment in the header -- moved it out to the cpp file. New try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=dcc4015d1da7

Was missing an include of UniquePtr.h https://treeherder.mozilla.org/#/jobs?repo=try&revision=64cfc40cc44f

Hi, part 3 fails to apply: renamed 1134865 -> Bug-1134865---Part-3-Add-JSubiNodejsObjectConstruc.patch applying Bug-1134865---Part-3-Add-JSubiNodejsObjectConstruc.patch patching file js/public/UbiNode.h Hunk #5 succeeded at 591 with fuzz 1 (offset -1 lines). patching file js/src/vm/UbiNode.cpp Hunk #3 FAILED at 224 1 out of 3 hunks FAILED -- saving rejects to file js/src/vm/UbiNode.cpp.rej patch failed, unable to continue (try -v) patch failed, rejects left in working dir errors during apply, please fix and refresh Bug-1134865---Part-3-Add-JSubiNodejsObjectConstruc.patch could you take a look, thx!

remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/50dedbefd46e remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/626f0dd608b0 remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/ada25868ffa6

https://hg.mozilla.org/mozilla-central/rev/50dedbefd46e https://hg.mozilla.org/mozilla-central/rev/626f0dd608b0 https://hg.mozilla.org/mozilla-central/rev/ada25868ffa6