Created attachment 569762[details][diff][review]
patch
With JSObject and Shape at their target sizes for object shrinking, there is still fat to remove from JSFunction.
- u.i.skipmin is unused, and can be removed.
- u.n.trcinfo is only used by the tracer, and can be removed. If JM ends up being able to call traceable natives we could find a more space efficient way to add this back.
- the parent object always has two fixed slots, which eat a lot of memory and need to be removed where possible.
The attached patch does these. The fixed slots are removed by using both a JSFunction and a FunctionExtended which is a subclass of JSFunction with storage for the extra data. Functions can be allocated from either size class (JSObject_Slots* finalize kinds are used to avoid unnecessary arena fragmentation).
On 32 bit platforms, normal functions are now 8 words and extended functions are 12. Measuring on membench50, about 75% of created functions have the normal size. Since more than half of object memory is used for functions, distinguishing the two saves about 20% of total object memory usage.

Created attachment 570039[details][diff][review]
followup
Missed places in CTypes and the jsworkers shell which assumed functions had reserved slots to access (browser built and worked, but make check failed). Also cleans up the API a bit and adds explicit friend API functions to use when a native with reserved space is needed.

(In reply to Andreas Gal :gal from comment #4)
> Maybe a public api is better. Lets avoid those nasty friend APIs.
I disagree. Since there was previously no public contract (that I can find) concerning how many reserved slots a function had, adding a public API and guarantee of >= 2 reserved slots for natives) would just be turning a current perf hack into a external commitment which will inevitably get in the way of future optimizations.

(In reply to Jeff Walden (remove +bmo to email) from comment #7)
> Rather, mozilla::ArrayLength, in the mozilla namespace, where it was defined.
Yes, I see you (and only you, it would appear) have been doing that. js:: is valid, looks less out-of-place, and coincides with the view that mfbt is a shared subset of utilities between js:: and mozilla::, not a utility imported from a foreign library.

(In reply to Jeff Walden (remove +bmo to email) from comment #9)
> I would not say its functions and classes are shared between the two.
That was, like, literally the reason we started mfbt: share reusable code.
(In reply to Jeff Walden (remove +bmo to email) from comment #10)
> As for "only [me]", I submit that this is because I've been the one touching
> [...] things in mfbt that the JS engine will use.
Nope; we all have (DebugOnly, Maybe). You've just been the only one to touch mfbt utilities outside namespace js so far.
Using mozilla:: instead of js:: doesn't help anything; it doesn't help the uninformed reader find the definition since (1) most uses are unqualified anyway (2) mfbt is outside js/ so regardless of what namespace prefix you see, you'd need to use mxr/dxr/ctags if you didn't know where to look. Because of (1), use of mozilla:: is just a low-frequency poke in the eye.
Sorry, don't mean to hijack the bug; it'd just be nice to get consensus before we have another style bifurcation.

Reuse, not share. (Shades of angels and pinheads, I know.) mfbt should be able to evolve mostly independently of Gecko and JS, except to the extent that a change must propagate into both. And I have some hope that it will be usable by non-JS stuff eventually -- think the crash reporter app, for example (which would obviate its special need for a change like bug 688877 comment 13). Saying that mfbt is a JS thing will make that very hard, as I doubt the crash reporter wants any more code inside it than it can help, given its nature.
Using mozilla:: makes all uses across the codebase consistent. It means someone changing mfbt stuff in some way doesn't need to use such things differently in JS than in the rest of the codebase. This will become increasingly common as mfbt gets fleshed out. That means we don't have to make an effort to hold some sort of line on this against entirely routine refactorings by "external" people.
I think it entirely reasonable to assume that readers in JS who see mozilla:: will look for a namespace mozilla. That that doesn't reside in js/ doesn't seem like a problem to me. They have to download the entire mozilla tree to get just JS, so it's unsurprising that some JS code resides outside js/.

(In reply to Jeff Walden (remove +bmo to email) from comment #12)
You are arguing in the limit for a function that is small and shouldn't be increasing (code outside namespace js). Actually, the function should be decreasing so the pragmatic thing now is for me to stop arguing since the argument will eventually become moot (modulo the unnecessary "using namespace mozilla;" you have sprinkled around, presumably to preserve our Purity of Essence). I'll do that.

Note

You need to
log in
before you can comment on or make changes to this bug.